In message <199508152039.NAA15590@ix7.ix.netcom.com>, Bill Stewart writes:
At 09:52 AM 8/15/95 -0400, you wrote:
I have recently started writing a small pair of encription and decription programs. I was planning of gennerating the key by taking the MD5 of the text password supplied by the user.
A reasonable approach, but be careful in your implementation. I haven't seen the book "A Million Wimpy Passwords and their MD5s" yet, but the CD-ROM version may be out soon :-) And you can probably ftp it from dockmaster.
I don't know what can be done here other then encuraging the user to use a long password. [...]
IVs are designed to let you put random stuff in them to discourage known-plaintext attacks, replay attacks, etc. However, suppose you take a known 64 bits from MD5(password) and put them in the IV - instead of the Bad Guy needing to brute-force 168-bit-deep Triple DES, he gets to brute force MD5s of human-selected passwords instead, which makes a lot of pre-computation possible.
Don't I need to know what goes into the IV? I can't just stick random stuff in it - I need to stick something that is a function of the passphrase into it (or make the user remember something my program spits out).
Also, for 3-Key Triple-DES, how do you get 168 bits of key from 128bits of MD5? (for 2-Key 3-DES, you only need 112 bits...) If you do something like M1=MD5(Key), M2=MD5(M1,Key), realize you've got at most 128 bits of real key instead of 168, though that probably needn't worry you too much...
Oh, I was going to do a MD5 of half of the passphrase to get one key pair, then MD5 the other half to get another key, and that left about 64 bits to play with.... [...]
Or am I better off putting the extra 64 bits of "key" into the IV, and generating a strong random number to stuff in the first block - since the decoder can just ignore that block anyway. Put the strong random number in the IV, if you've _got_ a source of strong random numbers...
Don't I need to reproduce the same IV during the decryption?
You might want to do something fancy like choose a random salt, use the salt for the IV, and use MD5(salt,human-selected-key) for the key. This makes pre-computation much less useful (unless you're careless and use MD5(key,salt) instead if MD5(salt,key)...), and means that you use a different session key for each batch of stuff you encrypt, even though you're using the same key. If you're paranoid about replay attacks, you could let some of the bits of the salt be random and some be a counter, and never accept a key smaller than the one from the previous successfully-decrypted message.
Hmmmm, so I should put the salt in the clear at the start of the file? This looks like an intresting idea. (it occurs to me that I never mentioned what my "sample application" was - I was thinking of encryption backup tapes so they can safely be transported off site and stored.)