On Mon, Sep 16, 2013 at 3:36 PM, Tony Arcieri <basc...@gmail.com> wrote: > On Mon, Sep 16, 2013 at 3:22 PM, Fabio Pietrosanti (naif) > <li...@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]. Trevor [1] https://docs.google.com/a/chromium.org/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit [2] https://whispersystems.org/blog/simplifying-otr-deniability/ http://www.isg.rhul.ac.uk/~kp/ModularProofs.pdf [3] http://codesinchaos.wordpress.com/2012/09/09/curvecp-1/ _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
