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