Re: [TLS] Using Brainpool curves in TLS

[Johannes Merkle <[e-mail]>]

>>> What problems does this solve? The Brainpool curves still have
>>> unverifiable construction,
>>
>> This is plain wrong. Obviously, you have not read RFC 5639. The construction of the Brainppol curves is completely
>> verifiable, only based on the fundamental constants Pi and e.
> 
> Repeating others arguments:
> 
> "Several unexplained decisions: Why SHA-1 instead of, e.g., RIPEMD-160
> or SHA-256? Why use 160 bits of hash input independently of the curve
> size? Why pi and e instead of, e.g., sqrt(2) and sqrt(3)? Why handle
> separate key sizes by more digits of pi and e instead of hash
> derivation? Why counter mode instead of, e.g., OFB? Why use
> overlapping counters for A and B (producing the repeated
> 26DC5C6CE94A4B44F330B5D9)? Why not derive separate seeds for A and B?"

The fact that the source of the seeds is explained is a huge step towards complete transparency as compared to the NIST
curves. Your arguments refer to the procedure for derivation of the parameters from the fundamental constants. There is
no canonical choice for such a procedure; the most obvious approach was to take it from ANSI X9.62, which we did.
Admittedly, we introduced a slight change: we use the first two PRNG outputs as coefficients a and b, whereas ANSI uses
the first PRNG output as r=a^3/b^2 and selects a and b arbitrarily with that relation); but this change is rather small
and quite straightforward. IMO there is really not much room left for conspiracy theories.

Anyone who is so paranoid (in the positive way which is useful for IT security professionals) to fear that a backdoor
may have been built in by tuning the parameter generation procedure should also question all design criteria for any
other curve, including Curve25519. There is always room for choices.

Johannes