[Cfrg] Fwd: Re: Safecurves draft

[Alyssa Rowan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 08/01/2014 23:50, Watson Ladd wrote:

> I don't want to rename curves because that induces consistency 
> issues.

Entirely accepted: I raised it merely as a question. People are
already beginning to adopt these curves of their own volition, so
changing the names of them could be confusing, yes.

As other have raised, putting the ladders in the appendix would
definitely be a good idea, and we need to explain the criteria under
which they were designed, which is what makes them so useful.

And yes, we should definitely get some OIDs. (However you actually
_do_ that. I've no idea.)


On 09/01/2014 01:32, Paul Lambert wrote:

> Comment: -too terse

It's an early draft. There's some fleshing-out still to go.

> - no clear mapping of numbers to variables - no documentation of 
> Edwards point addition Which is different from durrent ECC drafts

See above. Agreed.

> - no indication of security concerns and need or lack of checking 
> public key values

Important advantages. We should cover this, I think.

> Here¹s how I¹d document curve parameters: […python…]

> PS - above parameters are directly executable Python code Why use 
> pseudo code when you can use real code :-)

Advantage: People can copy-and-paste it into their implementations.
Disadvantage: People will copy-and-paste it into their implementations.

I honestly don't know which practice is preferable.

Naïve Python implementations directly using the bignums rather than
the good addition ladders probably wouldn't be constant-time - would they?


On 09/01/2014 03:11, Dan Brown wrote:

> I don't object to these curves.

Cool.

> […several objections to the name ‘safe’, implying other curves 
> aren’t, raising the NIST curves…]

As the SafeCurves criteria clearly explains:

• Their design criteria are transparent, and rigid, with few
  opportunities for an attacker to secretly select cryptanalytically-
  useful choices¹.

• They support simple, fast, complete, constant-time single-coordinate
  single-scalar and multi-scalar multiplication techniques which work
  in every case.

• These can be implemented using relatively-simple (compared to short
  Weierstrass) ladders which are both constant-time, and extremely
  efficent.

• They have large complex-multiplication field discriminants; are safe
  against additive and multiplicative transfer; and have secure twists.

Compared to the curves we've got at the moment (most of which don't
even have clearly-explained design criteria, and the ones that do are
unfortunately inefficient), the choice of name seems entirely apt to me.

Besides, it's what they're already widely known and referenced as:
people are already in the process of implementing these. As above,
changing it probably wouldn't be helpful and would just confuse people.

___
1. Contrast, say, the NIST/SEC curves generated by Certicom, whose
   design criteria are what I can only describe as “opaque” —
   mysterious black-box values which SHA-1 hash out to “provably
   random” parameters, but which are not in fact random themselves:
   the design team minted those values via repeated iteration to
   deliberately and secretly ensure they would meet some set of
   criteria (and then even listed the prime order in decimal to
   disguise the structure).

  (Sources are under the impression that was actually a set of
   criteria to ensure the curves would be efficiently implemented via
   Certicom-patented methods, but unfortunately, cannot state for sure
   that the criteria didn't also include cryptanalytically-useful
   weaknesses, and of course, that's what people are worried about,
   given the news. They didn't actually _see_ any attempt to actually
   weaken the NIST curves, they can at least say that much — phew —
   but that's little help in positively assuring it didn't happen.)

   These have no such concern.

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJSzln0AAoJEOyEjtkWi2t6lRYQALaYZ6LhxWSrMYo0sc/YzMyB
7Way2DfLQU6Vfg/CKae4IU6MmAvsaU6jgnHGwa0hA0MK0HCNaSqEOESxBQ9Mfb1j
AGX3+hhf004RVmKE/0DTElbLKXQM5ijRVdLZ7W84SsJviKceyX7wzdtgrLdnkjFb
32M+t0MJg7WCWcSZUTosNCW7b99gRZIcNe/eB5rFQhmxyVZHpj2aNDAYlVbX/H3q
xdkAVIw/N/qt2Q6F1RoKSfbFYGQTkTTXgYT6Bbt1f9iDGldiS5EVkLjvVugHAHfU
uVfUOdr920vsoXtxqwx4y2HgmQu7/UlHlxYCm+dPq3Rld3HhY56FY79vbl9Uzz+/
iCkQ+NqOi90hN0UQrbdKnfTgiWi+EMkQa+UhQGHtLli+b9cA+fELsYqTq2cfHLoR
ZcZQk5Ugrld7hej7itDQsIDs5rcmrdQAnb8LWSSeOvDwobu7YhVZMnVlKOS7120W
HOCAhiotGTVizGJ09Gskx1tweAoA35b0Vd6y2l7NW9SEpKeQwjuqPN8yzH4vCeq6
iqFVPu3Y8H0Io3+JZLaLyXXfyanpSd0KYEbSsgBpIwwpK7vLcQp23WzGgv46m1V7
0caZhNDQp3PNlsaAkKVu8V92VB/LHcA5f0nynKopg8U4DnMJtpCtuO12LPvYYrzm
bIv3ZVlXPvksHLr1fBJJ
=Jzw0
-----END PGP SIGNATURE-----