Subject: [Webpush] Curve25519

From: Adam Langley <[email-masked]>
Date: Wed, 29 Jul 2015 16:09:16 -0700

I've been asked by a couple of people to comment here on the choice of
elliptic curve as I'm an editor of draft-irtf-cfrg-curves.

I believe that new IETF work should be using curve25519 unless it's
incremental work on an existing standard where P-256 is dominant.

Representing my employer, it is also Google's view that using
curve25519 is strongly preferable to P-256 where possible. We're going
to take a pretty dim view of new work that uses crufty curves.

Although I'm aware that some people have reservations about the
construction of P-256 and worry about deliberate weaknesses, I do not.
But one doesn't need to believe that in order to recognise that P-256
is complex, slow and fragile.

I'm told that availability is a reason cited for wanting to pick P-256
(and PHP was mentioned). But AES-GCM is already (sadly) fairly
obscure. Apart from the side-channel concerns in many implementations,
AES-GCM is a good choice for an AEAD, but it's likely to present
greater implementation problems than curve25519. In practice, I
suggest that most implementations will ship their own copies of both
AES-GCM and whatever curve is needed and, in that case, curve25519
will be smaller and easier.

A Google search for "PHP curve25519" turns up an MIT licensed, pure
PHP version as the first result[1]. If people are concerned about the
license, or implementations for some other language, then please let
me know. The public domain ref10 or TweetNaCl[2] are generally readily
portable to any language and are simple and constant-time.

Lastly, I think my colleague, David Benjamin, has pointed this out
already, but private keys are private and public keys are generally
not. It's odd, and that translates as questionable, to depend on the
secrecy of a public key for authentication. By my reading of
draft-thomson-webpush-encryption-01 [3], that's currently the case.

Cheers

AGL

[1] https://github.com/lt/PHP-Curve25519
[2] http://tweetnacl.cr.yp.to/index.html
[3] https://tools.ietf.org/html/draft-thomson-webpush-encryption-01

---

From: Adam Roach <[email-masked]>
Date: Wed, 29 Jul 2015 21:38:13 -0500

> draft-thomson-webpush-encryption-01 [3], that's currently the case.

Can you be more specific about your misgivings here? Do you have some 
concrete attack in mind, or are you just wary of novel application of 
asymmetric keys that don't conform to the traditional public/private model?

By my reading, the current proposal is congruent with the use of bearer 
tokens for authorization, and we understand the properties of that kind 
of system pretty well. As a consequence, the point that you and David 
raise seems to be an objection to terminology -- treating "public" as an 
English word instead of a term of art -- rather than an issue with the 
way the underlying cryptography is being used.

That said, you live and breathe this stuff, while I only make use of it 
and presume it works. I would expect that, if there is a flaw here, 
someone with your background would be able to raise a specific, concrete 
objection.

/a

---

From: Adam Langley <[email-masked]>
Date: Thu, 30 Jul 2015 14:20:45 -0700

> asymmetric keys that don't conform to the traditional public/private model?

Mostly it's a wariness, but here's a possible concrete problem:

Implementations don't consider public keys to be secret. If this
protocol is extended in the future and ends up using signatures, then
verification of a signature by a public key will often leak
side-channel information because all the inputs are "public". It would
even be plausible that an implementation of a scalar-multiplication
could leak information about the "public" key as long as it didn't
leak information about the private one. (Although I'm not aware of any
implementations that actually act like that.)

But I think the wariness is actually the bigger issue. It's died down
recently but, for many years, people would think that "SSL 3.0" was
superior to "TLS 1.0" etc because the number's bigger. It's wrong, but
I understand where the confusion comes from. People would only enable
SSLv3 because it's the "best"!

Likewise, if people are worried about implementations in various
languages then they are expecting many implementations. When some poor
implementation screws up because they didn't understand that the
public key is private then I'll, likewise, have quite a lot of
sympathy for them.

(We also need to ensure that the encoding of secrets in this protocol
is constant-time as base64 generally isn't, but that's the case no
matter what is used.)

Cheers

AGL