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-----
participants (2)
-
futplexï¼ pseudonym.com -
Mark Grant, M.A. (Oxon)