Re: Use of the IV in DES & stuffing the first block w/ random stuff
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.
Seeing that I have 64 bits left over (MD5 gives me 128 bits, single DES needs 56, tripple DES needs 168 - so I have a bit over 64 bits left in both cases), is there anything useful that I could do with them?
Does setting the IV (normally left at zero) buy me anything?
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. 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...
Does cramming it into the first data block help protect me from known plaintext attacks? (I was going to use CBC so unless they know the first block they can't use a known plaintext attack, right?) Won't hurt, as long as you remember to remove it on the decrypt-end.
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...
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. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #--- Storyteller makes no choice - soon you will not hear his voice. His job was to shed light, and not to master. RIP, Jerry
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.)
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.
What I do in Curve Encrypt for the Mac is use the MD5 of the pass phrase, a 128-bit random salt (overkill is cheap here) and a one-byte counter field passed repeatedly through MD5, like this: <bare key> = MD5[<pass phrase>] <salt> = 128 bits of randoms <counter> = 0 MD5Init() for (a tenth of a second) MD5Update[<counter><key><salt><key><salt>] <counter> = <counter> + 1 <key> = MD5Final() At startup, the program determines how many iterations of MD5Update can be accomplished in a tenth of a second on the current CPU, and the loop is run that many times. The number of iterations and the salt are stored with the encrypted file, in the clear. The point to the <counter><key><salt><key><salt> concatenation is that this buffer is 65 bytes long, and MD5 works on 64-bit blocks, so that the buffer is shifted by one byte in the MD5 block each iteration, making precomputation of the MD5 addition steps more of a pain. Also note that the buffer is _not_ repeatedly MD5-hashed, but repeatedly sent to MD5Update() instead. This is out of fear that there might be fixed-points in the hash algorithm. -- Will
participants (3)
-
Bill Stewart -
Josh M. Osborne -
W. Kinney