Can you break my encryption protocol ?

I'm trying to put together a simple protocol for encrypting confidential
but typically low-value data (i.e. I don't want people to be able to read
it, but in most cases it wouldn't be catastrophic if they could). I want
it to be completely license-free, so I can't use RSA or other patented
algorithms. It also would only be used inside one organisation, so key
management isn't so much of a problem, and the main attack it has to 
defend against is packet-sniffing on the Net. It also has to support 
variable-length keys for ITAR.. 

The idea is as follows..


Client and server both have copies of a passphrase, of any length.

When starting the connection, client sends 128 random bits to the server.

Both ends take this data, append the passphrase, and use MD5 to generate 
a session key. If a key of less than 128 bits is required for legal 
reasons, then the appropriate number of bits are retained, and the rest 
replaced with bits from the random data that was sent in the clear.

That is, if you're only allowed 40 bit security, you take the first 88
bits that you were sent, and append the last 40 bits of the generated key 
to give you the session key to use.

You then go off and encrypt the session (probably using 3DES or Blowfish). 


Can anyone spot any flaws in this system ? The only potential problem I
can see would be that by cracking a number of sessions you could work out
the passphrase. However, I think the number required would still be
infeasible. 

Also, are there any known problems with using Blowfish for encrypting a
data stream ? I'm assuming it's OK as it's used in PGPfone. 

	Mark

-----BEGIN PGP SIGNED MESSAGE-----

Mark writes:
[description of threat model elided]
> Client and server both have copies of a passphrase, of any length.
> 
> When starting the connection, client sends 128 random bits to the server.
> 
> Both ends take this data, append the passphrase, and use MD5 to generate 
> a session key. If a key of less than 128 bits is required for legal 
> reasons, then the appropriate number of bits are retained, and the rest 
> replaced with bits from the random data that was sent in the clear.
> 
> That is, if you're only allowed 40 bit security, you take the first 88
> bits that you were sent, and append the last 40 bits of the generated key 
> to give you the session key to use.

So this is:

Salt = RNG(128,Seed);
SessionKey = MD5(Salt | PassPhrase);

Or for export:

Salt = RNG(128,Seed);
Temp = MD5(Salt | PassPhrase);
SessionKey = 
    (Salt[1..(128 - NumExportBits)] | Temp[(128 - NumExportBits + 1)..128]);

Sounds good, assuming the passphrase is nice and long (i.e. 128 bits, or
NumExportBits) and MD5 holds up.

If you haven't already, you might want to look at some of the work Hugo
Krawczyk and some others have been doing on keyed MD5. Their application is
different (primarily, authentication) but I think many of the concerns are
similar. Look for draft-krawczyk-keyed-md5-01.txt in the usual places. "It
is not appropriate to use Internet Drafts as reference material, or to cite
them other than as a ``working draft'' or ``work in progress''."

Futplex <futplex@pseudonym.com>

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBMPLHrCnaAKQPVHDZAQEoNQf/UCk2GwCMDqjodyqqduEUrbcOZFyBXsuV
RPSUqgo7GcJ7HpPqzgQyEREW71g9iSfpzqMDihjjJK1SJGfKS6dy60wYSbYtNrta
sEeLWDfpABTW7CgbpYaeDrMug1ASmcRThjeTzRqXyhUiWDFloNw7yASnyzbH4o+M
cVgwSTTBlvvxpvgOnXtLpr85a14FBBOXlsq5dWcaUW2V0+bt6qsbgeLqTUpCrtn5
dkzjprekBIxxQOwFh9vSKjXaBdhZAgmzI0nRVOmOBAxj2KSoGHqKwpUmQfx7yZeP
nJuGUPA0E+hgmPqTBv6e9CQSZmpY+x932YH7jWOrgscS/HQJYLq+4g==
=nyGN
-----END PGP SIGNATURE-----