Re: [TLS] Twist security for brainpoolp256r1

[Oleg Gryb <[e-mail]>]

----- Original Message -----
> From: Oleg Gryb <[e-mail]>
> To: Alyssa Rowan <[e-mail]>; Oleg Gryb <[e-mail]>; Manuel Pégourié-Gonnard <[e-mail]>; Johannes Merkle <[e-mail]>; "[e-mail]" <[e-mail]>
> Cc: 
> Sent: Saturday, November 15, 2014 8:30 AM
> Subject: Re: [TLS] Twist security for brainpoolp256r1
> 
> 
> 
> 
> 
> ----- Original Message -----
>>  From: Alyssa Rowan <[e-mail]>
>>  To: Oleg Gryb <[e-mail]>; Oleg Gryb 
> <[e-mail]>; Manuel Pégourié-Gonnard <[e-mail]>; 
> Johannes Merkle <[e-mail]>; "[e-mail]" 
> <[e-mail]>
>>  Cc: 
>>  Sent: Saturday, November 15, 2014 12:50 AM
>>  Subject: Re: [TLS] Twist security for brainpoolp256r1
> 
>> 
>>  No, you just don't have the optimisation turned on: that's using 
> the
>>  old unoptimised generic prime routine.
>> 
>>  If you're on 1.0.1, Configure/make depend/make it with flag
>>  enable-ec_nistp_64_gcc_128 (if you're on x86-64) to use the agl/Emilia
>>  Kasper optimised secp224r1/secp256r1/secp521r1 routines, because
>>  they're not on by default.
>> 
>>  Or try the 1.0.2 trunk for Intel's even faster AVX2 assembly routines.
>> 
>>  You will need to make sure it's using the correct library version.
>> 
>>  P256 can go at least twice as fast as that, and then some, and that
>>  should be about what you're seeing.
>> 
>>  Brainpool, unfortunately, just can't go that fast; the pseudo-random
>>  primes don't have a structure which allows optimisation. But if a
>>  generic multiplier is OK for your performance needs (like you're using
>>  here, or if you have hardware which can do it well), Brainpool will be
>>  okay.
>> 
> 
> 
> Thanks, it's very helpful and I'll try. Judging from multiple Linux 
> forums it's recommended and its estimated speed increases is 2x for ECDHE, 
> less so for ECDSA though. I'm wondering why no-ec_nistp_64_gcc_128 is still 
> a default. Are there any indications that either multiplier algorithm or its 
> openssl implementation are error prone?

> 


Yet another thought that I believe, I've seen somewhere in a an EC discussion. If there is a shortcut that allows simplifying EC arithmetic significantly, doesn't it mean that an attacker might be in a very good position to eventually find a way of decreasing a cost of attack significantly as well?

I understand that this is just a "common sense" argument, but I think that it correlates well with EC's "spectral weakness" discussed by Dan Brown, DJB and others here: 
http://www.ietf.org/mail-archive/web/tls/current/msg10169.html