in reply to Re^6: Calculating corruption
in thread Calculating corruption
the whole point of encrypting a message or a file is to make it look as a random stream of bytes as possible.
Actually, no. The whole point of encrypting a message is to make it so that no information about the plaintext is derivable from the encrypted file. This does not entail that every sequence of bytes is equally likely, only that every sequence of bytes that could result from an encryption (*) is equally likely given a particular expected distribution of plaintext messages which may not actually be uniform (**)
(*) If, for example, the encrypted files always begin with a prefix specifying the encryption method, or have a checksum/hash field that always matches the rest of the ciphertext, then only certain strings are possible. (And this answers the poster's original question of how you tell there's corruption, i.e., if there's an impossible prefix or the checksum is wrong, then you know, and this is the only kind of corruption you can catch.)
To be sure, if another of your goals is to efficiently utilize bandwidth, then it will be to your advantage to have as much of your message be random noise as possible (say, by leaving out the checksum and the prefix), depending on how important this second goal is.
(**) And then imagine how fun things get if, say, your only possible plaintexts are "YES" and "NO" and "YES" is expected to occur 80% of the time.
|
|---|