[14347] in cryptography@c2.net mail archive
Re: New authentication protocol, was Re: Tinc's response to 'Linux's answer to MS-PPTP'
daemon@ATHENA.MIT.EDU (Guus Sliepen)
Tue Sep 30 16:58:45 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Mon, 29 Sep 2003 20:10:44 +0200
From: Guus Sliepen <guus@sliepen.eu.org>
To: Bill Stewart <bill.stewart@pobox.com>
Cc: cryptography@metzdowd.com
In-Reply-To: <4425.216.240.32.1.1064854280.squirrel@smirk.idiom.com>
--6pbY/KU4ayLo+qis
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Sep 29, 2003 at 09:51:20AM -0700, Bill Stewart wrote:
> > =3D=3D=3D=3D=3D=3D=3D=3D=3DStep 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).
>=20
> 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 1.2.3.4", 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.
>=20
> 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.
--=20
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus@sliepen.eu.org>
--6pbY/KU4ayLo+qis
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/eHWiAxLow12M2nsRAqFdAKCCE8Ti5XwhnLrnMpmx+kZPanrsRgCfadRl
FiefVzWexgeXF1j6NeZCcqA=
=gl3o
-----END PGP SIGNATURE-----
--6pbY/KU4ayLo+qis--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
