[Cryptography] We need a new encryption algorithm competition.

[ianG]

Thanks to Adam!

On 18/03/2014 22:50 pm, Tony Arcieri wrote:
> On Tue, Mar 18, 2014 at 1:40 PM, Krisztián Pintér <pinterkr at gmail.com>wrote:
> 
>> i would really appreciate some expert opinions on curveCP. this thing
>> is out there for years, and all i hear is silence.


Well, DJB in curveCP makes a very good point:  Now that EC is fast
enough for the average app to ignore the cost, why not move to a pure
single request-response-PK-encrypted model?  Instead of the older
performance-dominated model of PK-signed-key-setup + RR-key-encrypted?

For fast turnaround this is much easier, but the iceberg below the
waterline here is that the coding of the former is much much easier,
about an order of magnitude.

Personally, I buy the argument because I wrestle with the iceberg, but
there is one counter-argument which holds me short of the conclusion,
which is side-channel attacks.  Many side-channel attacks are conducted
where repeated access to the PK pair is possible, and the latter model
reduces that possibility a lot.


> Well first, the CurveCP implementation isn't usable. It's not really a
> library so much as external programs you can talk to which handle the
> termination.
> 
> Another part of the problem is CurveCP is built on UDP. I'm not really sure
> why it's built on UDP


I do the same thing, I've worked to move all my stuff into UDP.  The
reasons are many and various and sometimes not particularly well
founded.  Here's one attempt:

http://iang.org/ssl/reliable_connections_are_not.html

So I strongly empathise with DJB on this, but I can't explain it
quickly.  Note the same desire over at QUIC.


> as djb classes TCP Vegas decongestion as "good":
> 
> http://curvecp.org/decongestion.html
> 
> UDP is often dropped on the floor amidst TCP congestion, as this
> experimental measurement of CurveCP demonstrates:
> 
> http://www.delaat.net/rp/2010-2011/p48/report.pdf


Yeah, basically this is an early-optmisation asumption.

The benefit of using UDP in a performance process is not overall
bandwidth of a packed tube nature (which logically TCP might be better
at, except for the in-order deliver constraint) but fast turnaround,
faster startup and lower overall packet load.  And as he admits in the
paper, he didn't go there: "When used for short connections (i.e.,
transfer of a small amount of data) however, CurveCP uses significantly
less traffic than either HTTPS or SSH. This has not been quantified
yet.[6]"  So to some extent, he might have picked a less interesting cherry.

If CurveCP is interesting, I'd suggest also reading the QUIC discussion
here:

https://docs.google.com/a/google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/preview?sle=true&pli=1#

especially where they get into comparing how TCP does it, and the
difficulties this presents.


> See chart on Page 15, "CurveCP bandwidth with competing TCP traffic
> (10MBit)"
> 
> CurveZMQ has reimplemented CurveCP on top of TCP, but it has been
> special-cased for the 0MQ protocol:
> 
> http://curvezmq.org/
> 
> Then there's MinimaLT:
> 
> http://cr.yp.to/tcpip/minimalt-20130522.pdf

nice!  On my must-read stack.  Somewhere near mosh :(



iang