[Cryptography] composing EC & RSA encryption?

[Bill Cox]

We need to move to more efficient protocols anyway, and this provides an
ideal opportunity to implement two-cipher-suite protection, IMO.

To enable zero-round-trip encrypted handshakes, the clients must retain
information about the server from prior connections.  This should include a
"long term key", such as regular DH-2048.  The first packet could be
encrypted using a secret derived from the long-term DH-2048 server key and
the local long-term DH-2048 key for that particular server.  This
computation only needs to be done once, or until we begin to feel that our
"long-term" keys are a little long in the tooth and need to be refreshed.

The first packet would not be forward-secure, meaning that if the long-term
key were stolen/broken, these packets could be revealed.  The first packet
should be a public "GET" request, and not passwords.

The first response from the server can be encrypted using an ephemeral ECDH
256-bit key.

The important step here is to insure that the ephemeral secret cannot be
guessed unless _both_ the DH derived secret and the ECDH derived secret are
cracked/stolen.  Simply computing SHA256(DH_secret || ECDH_secret) should
be good enough.  All packets after the first one can be doubly-secured, and
SFAIK, this does not present any new major burden on the protocols.  TLS
1.3 should probably do something like this to enable zero-round-trip
handshakes.  The improved security would be a side-benefit :)

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151025/3f138589/attachment.html>