[cryptography] Asynchronous forward secrecy encryption

Trevor Perrin trevp at trevp.net
Mon Sep 16 19:11:41 EDT 2013

On Mon, Sep 16, 2013 at 3:36 PM, Tony Arcieri <bascule at gmail.com> wrote:
> On Mon, Sep 16, 2013 at 3:22 PM, Fabio Pietrosanti (naif)
> <lists at infosecurity.ch> wrote:
>> Shouldn't we first try to improve Internet Standard, and only after look
>> for custom (and usually not interoperable) implementation?
> Well, if you want a forward secrecy for asynchronous communication using
> existing Internet standards, perhaps you could use DTLS?

I think Marco was talking about "messaging" cases where you don't want
the roundtrips of a TLS (or CurveCP) handshake.

> Call CurveCP "custom" if you wish, but it's the sort of thing that *should*
> be an Internet standard ;)

For another design with a lot of attention to forward secrecy and
immediate (zero-latency) sending, see QUIC [1]...

CurveCP spends 3 DHs, so it's computationally slower than MQV but more
complex than a Kudla & Paterson-style "triple DH" [2].  I also don't
think it's as amenable to "zero-latency" data transmission based on
pre-cached or pre-distributed ephemeral info as these other things.

CurveCP is also vunerable to impersonation of a client to a server if
either the client's ephemeral or server's key is compromised, which
are unusual properties for a key agreement protocol [3].


[1] https://docs.google.com/a/chromium.org/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit


[3] http://codesinchaos.wordpress.com/2012/09/09/curvecp-1/

More information about the cryptography mailing list