Re: [Cfrg] Progress on curve recommendations for TLS WG

["D. J. Bernstein" <[e-mail]>]

Is anyone actually planning to propose "random" curves here? Dan Brown
said he would but didn't follow through. Brainpool already has RFCs.

Johannes Merkle writes:
> Pi and e are by far the most prominent mathematical constants, while
> cosinus(1) (used in that analysis) is quite arbitrarily chosen.

MD5 uses sin(1). This is one of several "nothing up my sleeve numbers"
cited in http://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number.

Please point to the cryptographic papers disputing this "nothing up my
sleeves" designation and arguing that switching MD5 from sin(1) to e
would be less suspicious. Surely you're not claiming that the public
would have been more suspicious of cos(1) than of sin(1)?

> Keccak wasn't even invented at the time the Brainpool curves were
> generated.

Sure, but Brainpool could easily have argued for switching to the 1996
European hash function RIPEMD-160 from famed cryptographers Dobbertin,
Bosselaers, and Preneel. The SHA-1 critique in

   http://homes.esat.kuleuven.be/~bosselae/ripemd160.html

includes items from 2004 as the last three sentences but is otherwise
pre-2000 material. Do you seriously believe that switching from NSA's
SHA-1 to respectable RIPEMD-160 would have made people reject the
Brainpool curves as being potentially backdoored?

How about 192-bit Tiger, from famed cryptographers Anderson and Biham,
for extra security? Or RIPEMD-256? Or RIPEMD-320? Or one of the versions
of Whirlpool, from famed cryptographers Rijmen and Barreto? Or, back in
the NSA universe, SHA-256 or SHA-384 or SHA-512?

If you count carefully you'll see 11 different hash functions here, more
than the 10 Keccak versions that were used to manipulate BADA55-VPR-224.

> The method used to generate the coefficients of the Brainpool curves
> was taken from ANSI X9.62

http://projectbullrun.org/dual-ec/dualec-author.html illustrates NSA's
influence over ANSI. Anyway, what relevance does the identity of the
curve generator (or generators) have to the measurement of rigidity?

> There is only the slight deviation

So you're admitting that Brainpool _didn't_ actually take the same
method; it manipulated the method (to simplify it, you say). Even
without this admission, how exactly is the Brainpool procedure less
suspicious than the BADA55-VPR-224 procedure?

There's a "BADA55" in the BADA55-VPR-224 output, but a real attack along
the same lines wouldn't have anything obvious. Meanwhile the Brainpool
procedure has an embarrassing 26DC5C6CE94A4B44F330B5D9 overlap, which
you previously admitted was "unfortunate".

> But it is not ok to imply that the Brainpool curves could potentially
> have been designed with a backdoor built in.

The statement you're responding to is that the curve generator had the
flexibility to secretly choose from among more than 1000000 curves for
any particular prime. If the curve generator secretly knew a weakness in
just one of these >1000000 curves then the curve generator could have
chosen that curve.

You seem to think that the flexibility was somewhat less because (e.g.)
the public wouldn't have accepted cos(1). But this doesn't fundamentally
change the picture. I don't mean to exaggerate the risk here---note that
SafeCurves marks Brainpool's rigidity as an acceptable "mostly rigid"---
but I don't see how you can justify your claim of zero risk.

---Dan