On Mon, Sep 29, 2003 at 09:51:20AM -0700, Bill Stewart wrote: > > =========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). > > By "name of the tinc daemon", do you mean identification information? > That data should be encrypted, and therefore in step 2. > (Alternatively, if you just mean "tincd version 22.214.171.124", that's fine.
No, identification information. But still, it's just a name, not a public key or certificate. It is only used by the receiver to choose which public key (or certificate etc) to use in Step 2. This information does not have to be encrypted, it has just as much meaning as the IP address the sender has. > > 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. > > You can't encrypt the DH keyparts using RSA unless you first exchange > RSA public key information, which the server can't do without knowing > who the client is (the client presumably knows who the server is, > so you _could_ have the client send the key encrypted to annoy MITMs.) With tinc, public keys are never exchanged during authentication, they are known beforehand. And again, there is no distinction between a client and a server, it is peer to peer. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]>
Description: Digital signature