[Cryptography] We need a new encryption algorithm competition.

[Nico Williams]

On Wed, Mar 19, 2014 at 7:26 AM, ianG <iang at iang.org> wrote:
> 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.

The antecedents of "this" and "the former" seem to be the same,
therefore that makes no sense.

Anyways, fixed-keys [EC]DH is orders of magnitude easier (and, with
DJB curves) cheaper than just about any other type of PK key exchange
and authentication.  Plus you get to implement LoF/TOFU if you like,
and you can trivially bind-in a PFS exchange (ephemeral ECDH keys).

You could look at the old and very obsolete NFS AUTH_DH (later, the
GSS mech_dh mechanism) code...  Or DJB's modern variant of the... the
same idea.  You can see the simplicity there.

So I don't understand just what you're trying to say.  Can you clarify?

Also, I'm decoding "the older performance-dominated model of
PK-signed-key-setup + RR-key-encrypted" == RSA key transport TLS
ciphersuites.  I get that.  I don't get the "performance-dominated"
part, unless you mean that "RSA key transport" is cheaper than signed
PFS, which it used to be, but with modern curves that's no longer
true, and anyways, with fixed ECDH keys you get plenty of value.

> 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.

DJB addresses the security concerns of ECDH key reuse.  You should
read the relevant papers.  For the key sizes we're discussing there's
no issue for any realistic reuse rates.

>> 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

To save the TCP handshake cost.

If instead of ISNs + 3-way handshake you use a non-TCP 3-way handshake
with ECDH keys you get the same properties as TCP's 3-way handshake.
And then you get to implement TCP Fast Open like zero-message new
connection establishment.

You get more though.  You can easily implement things like mosh's
mobility semantics by using UDP (which is precisely why mosh uses
UDP).

I.e., IPsec, IP mobility, SCTP, these things have failed, and TCP is
not useful for long-lived connections in a mobile world.  Therefore
UDP looks like the best hope.

You do get to (must!) re-implement everything that TCP does regarding
congestion control, minus obsolete cruft.  And for better or worse you
get to do it in user-land (there's a lot written about user-land
TCP/IP stacks for high-performance servers, so don't discount the idea
out of hand).

> I do the same thing, I've worked to move all my stuff into UDP.  The
> [...]

Not surprising.  [Hopefully] good!  (i.e., if you implemented sane
congestion control, then good! else bad!)

>> 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.

Hopefully as we move more protocols onto UDP the routers/router admins
will drop the preference for TCP.  It may be touch-and-go for a while,
but c'est la vie.

Alternatives would be to develop TCP options for grafting
MinimaLT/CurveCP onto TCP, including mosh-like mobility support.
_That_ would be a good idea, if it's at all feasible (I'll have to
refresh my recollection of constraints on TCP options).  Then we'd not
have to worry about the middle boxes' preferences.  We'd have a bit
more overhead, and a lot of TCP's remaining problems (unless we
further evolved it with yet more options).

BTW, now you see why SDOs like the IETF don't just throw out old
broken things: it's bloody hard to deploy new things given the middle
boxes that exist now.  You can't build a new, parallel Internet.
Paraphrasing Bill Sommerfeld, we have to redesign and rebuild the
aging airplane as we fly it at cruise altitude and cruise speed.

Nico
--