Default ecdh curve order

[evilaliv3]

While experimenting within the Globaleaks application i've noticed that the default OpenSSL ecdh curve configuration seems to be x25519, secp256r1, x448, secp521r1, secp384r1.

This, in combination with SSL_CTX_set_ecdh_auto seems to cause that clients that support secp521r1, secp384r1 would prefer the less secure secp256r1.

I wonder which are the reasons for this default configuration and if it could be worth it to change it.

Thank you,

p.s.: my tests have been performed on Ubuntu 18.04 with openssl 1.1.1.

[kroeckx]

The p256 implementation has an assembler version that is a factor of 10 faster then the p384 impementation.

[kroeckx]

This is what I get:

curve	op	op/s
256 bits ecdh (nistp256)	0.0001s	11184.7
384 bits ecdh (nistp384)	0.0012s	821.4
521 bits ecdh (nistp521)	0.0005s	2080.5
253 bits ecdh (X25519)	0.0001s	16904.1
448 bits ecdh (X448)	0.0007s	1526.2

[kroeckx]

I guess I should also point at some other reasons why P384 and P521 aren't higher in the priority list. I might be wrong about some things, but it's at least my understanding of the situtation.

• Historically, P256 was the only implementation that had any form of side channel protection. I believe it's constant time, and that P384 and P521 are not.
• As far as I know, P384 and P521 just use the generic code, making them slower. On the other hand P256 had code written for it to do the math faster, and in general is just in better shape.

I think it makes more sense to switch to X25519 and X448. People that don't have those probably also don't have a good implementation for P384 and P521.

[evilaliv3]

I see, thank you for the explanation @kroeckx !

it make definitely sense especially in relation to the considerations about the constant time implementations in OpenSSL.

[mattcaswell]

This question seems to have been answered. Closing.