[108148] in cryptography@c2.net mail archive
Re: refactoring crypto handshakes (SSL in 3 easy steps)
daemon@ATHENA.MIT.EDU (travis+ml-cryptography@subspacefie)
Thu Nov 15 17:30:00 2007
Date: Wed, 14 Nov 2007 13:45:37 -0600
From: travis+ml-cryptography@subspacefield.org
To: Pasi.Eronen@nokia.com
Cc: cryptography@metzdowd.com
Mail-Followup-To: Pasi.Eronen@nokia.com, cryptography@metzdowd.com
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F2404DA7F68@esebe105.NOE.Nokia.com>
--V0207lvV8h4k8FAm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Nov 13, 2007 at 08:35:52AM +0200, Pasi.Eronen@nokia.com wrote:
> The "extra messages" might be irrelevant for cryptography,
> but they're not irrelevant for security or functionality.
> E.g. in SSL, you have capability/feature negotiation
> (cipher suites, trusted CAs, in TLS 1.2 also signature
> algorithms, etc.)
So, this is a good place to attempt to use this method.
Data to be sent:
1) supported capabilities on the client
2) supported capabilities on the server
3) negotiated capabilities
Dependencies:
1) No dependencies (first message from client to server)
2) No dependencies (first message from server to client)
3) Depends on #1 and #2
Results:
3 messages
1-1.5 RTTs (one if there's a simultaneous open, which is rare)
So unless I'm missing something, we're still at 3 messages.
Aside:
I would like to point out that TCP-based protocols have the latency
disadvantage of having to do a 3-way handshake before transferring any
data. If you were to design a new IP protocol, you could do the key
exchange within the handshake, which would save 3 messages, but may be
vulnerable to a resource-consumption attack on the CPU.
I wonder if we here could develop a handshake that was
cryptographically secure, resistant to CPU DoS now, and would be
possible to adjust as we get faster at doing crypto operations to
reduce latency even further. Basically an easy knob for balancing
high latency and DoS resistance vs. crypto overhead and low latency.
It should be adjustable on either end without altering the other.
--=20
Life would be so much easier if it was open-source.
<URL:https://www.subspacefield.org/~travis/> Eff the ineffable!
For a good time on my UBE blacklist, email john@subspacefield.org.
--V0207lvV8h4k8FAm
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (OpenBSD)
iQIVAwUBRztQYGQVZZEDJt9HAQKWfg//ZD9cEsSNd8LIF+0Lmqf0qWEzQxLKetL5
5WEv1sf3nEX2tq02t6ONaD5PnjF9vnwDC5Ka+JQGJghw+jAoA2K/XXf6N4pHu+fh
PFsVgmAK2ZlOLsPox2zg9Y+Sr1+Ld6M6XS0SIPOepboFo4d2YqGxt5GjCJyUpIWV
3Ef9qiH8rNh08YJyNlIB8OH7GYr7gE1XVpoz9wCIDTXXVMT+Lb4J1XPxOXCXSZ3r
GhW3a/22Z6+tzJg6w19zj1VGmLC41V0SdISfrLYIr7ZD3y1IZ/BN2+DRbKDGzmGt
pbFnNtC+tffcUoLo1PjfPbRE9cuMOJPz6v8+r86k6gwIK3iV9I5Gu4JBPsCUBjlS
i/iPhEfMJoz9OEqPR7vmUmHGtvoaGjDaNHbqt9kNWXaV9i8Rk/NHuzEw/xueTQT2
kztZbae8Hoa4rxYbZ+M4htdY6DCT0I/E6B1gwL4G+cCc50b4CHMxhstLhm1cAADk
Nc3WDy6kOfN9wfH1Zn7oSfFAxY1/3D/UsAf9BnfsQ0GA/MNsJn+hcicSdxwkrQVh
AmXyasFUxvxc5jVnk6RuEmCI5K92YlZhPnkznD3RfnSmwxX+ceOcdTG2ZTzM//OP
hdpy9qv+1Mvlcx8fK6Ur7f2DUFfbtveABY3y5rYccMAlhwdQeT10UGoYS/cwUMX6
SuPOD096vEM=
=Td7h
-----END PGP SIGNATURE-----
--V0207lvV8h4k8FAm--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
