Re: [TLS] Using Brainpool curves in TLS

[Nico Williams <[e-mail]>]

On Thu, Oct 17, 2013 at 3:59 AM, Johannes Merkle
<[e-mail]> wrote:
>> But the SafeCurves site doesn't focus only on construction rigidity,
>> and it doesn't discount Brainpool on account of rigidity in its
>> construction.  SafeCurves also covers other issues.  SafeCurves
>> declares Brainpool curves not safe according to the following
>> criteria:
>>
>>  - feasibility of efficient constant-time implementation
>>    http://safecurves.cr.yp.to/ladder.html
>>
>>  - twist security
>>    http://safecurves.cr.yp.to/twist.html
>
> These properties are clearly beneficial to secure implementations against side-channels and active attacks. But you can
> still achieve this resistance with other curves. The approach of Brainpool was different; we gave clear hints to the
> necessity of implementation security but left the details completely to the implementors.

I would say that providing hints as to how to implement in constant
time >> providing hints that implementations should be constant-time.
Everyone knows the latter.  Not everyone knows how to achieve that.

>>
>>    IIUC this means that when using non-twist secure curves one has to
>> validate that peers' public keys are on the curve being used, which in
>> turn would require exchanging not just public keys but also Schnorr
>> signatures (and, of course, verifying those signatures before using
>> peers' public keys for any other purpose).
>>
>
> Although I am familiar with Schnorr signatures, I don't understand how they should be used for point validation.
>
> Typically, you need to check that the public key satisfies the curve equation. For IKE, there was an RFC published on
> how to do this during key agreement.
>
> If you receive a compressed key, it suffices to uncompress the key; if successful, the resulting point is on the curve.

Yeah, that was a thinko; please excuse me.  Validating that the point
is on the curve was the point.  The fact that some curve has twist
security means that for DH there's no need to validate that public
keys are points on the curve -- i.e., all other things being equal,
such a curve is faster than a curve that doesn't have this feature.
Faster is important.

Nico
--