Guus Sliepen <[EMAIL PROTECTED]> writes: > On Sat, Sep 27, 2003 at 07:58:14PM +0100, M Taylor wrote: > TLS makes a distinction between a client and a server. If possible I > wish to avoid making that distinction. If possible, I would also like to > continue to be able to use an RSA public/private keypair. This made me > *sketch* the following _authentication_ protocol: I'm trying to figure out why you want to invent a new authentication protocol rather than just going back to the literature and ripping off one of the many skeletons that already exist (STS, JFK, IKE, SKEME, SIGMA, etc.). That would save people from the trouble of having to analyze the details of your new protoocl.
> ========== > Step 1: > Exchange ID messages. An ID message contains the name of the tinc daemon > which sends it, the protocol version it uses, and various options (like > which cipher and digest algorithm it wants to use). > > Step 2: > Exchange METAKEY messages. The METAKEY message contains the public part > of a key used in a Diffie-Hellman key exchange. This message is > encrypted using RSA with OAEP padding, using the public key of the > intended recipient. > > After this step, both sides use Diffie-Hellman to compute the shared > secret key. From this master key, keys and IVs for symmetric ciphers and > digest algorithms will be derived, as well as verification data. From > this point on all messages will be encrypted. Why are you using RSA encryption to authenticate your DH rather than using RSA signature? Depending on *exactly* how you do things, there are MITM attacks: Consider the following protocol: M1={DHx}RSAy -> <- M2={DHy}RSAx ZZ = DH shared key HMAC(ZZ,M1,M2) -> <- HMAC(ZZ,M2,M1) [Reverse order to prevent replay] Now, the attacker chooses 0 as his DH public. This makes ZZ always equal to zero, no matter what the peer's DH key is. He can now forge the rest of the exchange and intercept the connection. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]