From: Bill Stewart <stewarts@ix.netcom.com>
Date: Tue, 15 Aug 95 13:44:22 PDT
To: "Josh M. Osborne" <stripes@va.pubnix.com>
Subject: Re: Use of the IV in DES & stuffing the first block w/ random stuff
Message-ID: <199508152039.NAA15590@ix7.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


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