Slashdot Mirror
Encryption Matters, Part Deux
dlc writes "I'm sure Rusty has already submitted this, but just in case he hasn't, part 2 of "Encryption Matters" is now available on Kuro5hin.org. Part 1 was featured on Slashdot last week, and, if the lack of trolling is any indication, was well-received. "
Some grips:
"The solutions to the problems of shared secret exchange and weak encryption are actually quite simple."
In theory, the solutions are indeed simple, but securely implementation of the algorithms and the correct protocols to use are actually very intricate. For example, the article completely fails to mention man-in-the-middle interception and relay attacks on public key cryptosystems, nor does the article mention the importance of padding, the prevention of replay attacks on one-time nonces, and the dangers of chosen signature attacks. The article presents just enough detail that a reader might believe that the topic is covered throughly, but not enough implementation guidance that a naive reader would be able to use the information given in a reasonable secure manner.
"Additionally, the private key can be used to encrypt things. This allows anyone with the matching public key to verify the author's identity."
NO!!! The private key can be used to encrypt *only nonces that the owner of the private key can control* (message hashes and the like). This signed hash allows anyone with the corresponding public key to *verify that the hash was not modified in transit*; it says absolutely nothing about the author's identity, nor does it authenticate the contents of the message signed, beyond that the message was signed by a person possessing the corresponding private key and was not changed such that the contents hashed were modified.
"Given two cipher texts that have some form of key overlap, all a cryptanalyst has to do is "slide" them around until the number of coincidences suddenly jumps."
The method of Kasaki superpositions would not be used to solve two different messages encrypted with the same pad. Rather, one would XOR the two messages together at different offsets and compute what is known as the "text autocorrelation function" (Shannon roughness). Subsets of the XORed messages would be tested with the ACF until a certain subset more resembled English text. The I of C method does *not* apply in this case, because the assumption of multiple messages encrypted in the same polyalphabetic glyph set does not hold.
"It is known by many names; message digest, fingerprint, cryptographic checksum, contraction function, manipulation detection code (MDC), and message integrity check (MIC)."
These words are not neccesarily synonymns; it is a very sloppy use of these technical terms to use them interchangeably. A message digest refers to the output of a hash function on a specific message. A fingerprint usually refers to the output of a hash function on a specific asymetric key. A cryptographic checksum is not defined in any general usage; usually, it would mean the same as a message digest, but one would not be sure. A contraction function does not exist; compression functions do, but they are used within cryptographic hash functions in the Meyer-Damgard model of collision resistance. The terms "manipulation detection code (MDC), and message integrity check (MIC)" are not in common use, nor are their acronyms. The author may be referring to Message Authentification Codes (MACs), which are essentially keyed cryptographic hash functions.
"Also, a one-way hash function, when properly designed, will not give the same hash value for two different preimages"
The pigeonhole principle necesitates that there will be collisions once the preimage size exceeds the size of the hash value. Indeed, if the hash function is a "perfect" hash function, it will approxiamate a random function, not a random permutation on the inputs. One would expect to find a collision after 2^(hash length/2) tested preimages due to the birthday paradox.
"If your password is not something simple like an english word, it is probably secure."
NO!!! Unless your password has over 40 bits of entropy (about a random alphabetical 8 letter password, about 3 randomly selected
"By now you should have a good understanding of the fundamental concepts of encryption."
If you read just this article, you would have a flawed understanding of the "fundemental concepts of encryption," but you would believe that you *did* understand it. A little knowledge is sometimes a very dangerous thing. Any serious cryptographic implementor should definitely buy _Handbook of Applied Cryptography_ by Menezes, et. al., _Applied Cryptography_ by Schiener, and _Codebreakers_ by Kahn (for historical background).