refactoring crypto handshakes (SSL in 3 easy steps)

Pasi.Eronen at Pasi.Eronen at
Tue Nov 13 01:35:52 EST 2007

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.) which IMHO *is* important for 
security (if you consider the security implications of 
deploying this over tens of years and hundreds of 
millions of hosts).

(But yes, there are variations of SSL where a smaller 
number of RTTs might have been sufficient..)

Best regards,

> -----Original Message-----
> From: travis+ml-cryptography
> Sent: 08 November, 2007 21:50
> To: Cryptography
> Subject: refactoring crypto handshakes (SSL in 3 easy steps)
> Network latency is important, and will only become more so, since
> light won't go faster in a given medium, and we can't do better than
> c, ever.
> Refactor protocol to minimize number of interlocked steps.
> Specifically, reduce the number of messages.
> Identify data which must be transmitted, and identify their
> dependencies.  Send data on first outbound message to peer after all
> its dependencies are available (i.e. on the step after it is
> received).  Each transmission is a sweep of one level of the
> dependency tree, starting at the root and working downward.
> Three messages is the proven minimum for mutual authentication.  Last
> two messages all depend on the previous message, so minimum handshake
> time is 1.5 RTTs.
> First examine SSL with Mutual Auth, which is detailed here:
> authentication_with_certificates.png
> Here is a refactored version of the important messages:
> C->S: hello, RNc, client cert, enc_S(client_cert)
> S->C: server cert
> C->S: enc_S(PMS)
> Providing the datum as soon as its dependencies are satisfied is
> well-studied in processor design.
> One may have extra messages, but they are implementation artifacts,
> completely irrelevant to the cryptography.
> Network protocol libraries advance through time monotonically and thus
> are analogous to LR(1) language parsers which parse from left to right
> and are only able to look at the next token (message); perhaps we can
> apply what we already know about them to create unambiguous crypto
> handshakes with respectable error handling.
> Sending one layer of the dependency tree at once is like a synchronous
> circuit; one could also fire off messages as soon the data becomes
> available, like an asynchronous circuit, which may reduce overall time
> of the handshake due to computation by the endpoints.  However, it is
> an implementation detail, not important to this analysis.
> When would a handshake require more?  Is there such a thing, in any
> extant ZKS or PFS systems?
> -- 
> Life would be so much easier if it was open-source.
> <URL:> Eff the ineffable!
> For a good time on my UBE blacklist, email john at

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list