Subject: Re: [TLS] Twist security for brainpoolp256r1
From: Oleg Gryb <[email-masked]>
To: Alyssa Rowan <[email-masked]>, Oleg Gryb <[email-masked]>, Manuel Pégourié-Gonnard <[email-masked]>, Johannes Merkle <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sat, 15 Nov 2014 16:30:40 +0000 (UTC)
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>

----- Original Message -----
> From: Alyssa Rowan <[email-masked]>
> To: Oleg Gryb <[email-masked]>; Oleg Gryb <[email-masked]>; Manuel Pégourié-Gonnard <[email-masked]>; Johannes Merkle <[email-masked]>; "[email-masked]" <[email-masked]>
> 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?