How effective is open source crypto?

[Eric Rescorla]

Anne & Lynn Wheeler <lynn at garlic.com> writes:
> There is a description of doing an SSL transaction in single round
> trip. The browser contacts the domain name system and gets back in
> single transmission the 1) public key, 2) preferred server SSL
> parameters, 3) ip-address. The browser selects the SSL parameters,
> generates a random secret key, encrypts the HTTP request with the
> random secret key, encrypts the random secret key with the public key
> ... and sends off the whole thing in a single transmission
> .... eliminating all of the SSL protocol back&forth setup chatter.
You still need a round trip in order to prevent replay attacks. The
fastest that things can be while still preserving the security
properties of TLS is:

ClientHello       -> 
ClientKeyExchange ->
Finished          ->
                  <-  ServerHello
                  <-  Finished
Data              ->

See Boneh and Schacham's "Fast-Track SSL" paper in Proc.ISOC NDSS 2002
for a description of a scheme where the client caches the server's
parameters for future use, which is essentially isomorphic
to having the keys in the DNS as far as the SSL portion goes.

In any case, the optimization you describe provides almost no
performance improvement for the server because the load on the server
derives almost entirely from the cryptography, not from transmitting
the ServerHello [0]. What it does is provide reduced latency,
but this is only of interest to the client, not the server,
and really only matters on very constrained links.

-Ekr

[0] With the exception of the ephemeral modes, but they're simply
impossible in the scheme you describe.


-- 
[Eric Rescorla                                   ekr at rtfm.com]
                http://www.rtfm.com/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com