Bug 1021897 - Enable curve secp521r1
Summary: Enable curve secp521r1
Alias: None
Product: Fedora
Classification: Fedora
Component: openssl
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: FE-Legal ecc
TreeView+ depends on / blocked
Reported: 2013-10-22 09:46 UTC by Cesar Eduardo Barros
Modified: 2013-11-11 09:19 UTC (History)
14 users (show)

Fixed In Version: openssl-1.0.1e-31.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-11-11 09:19:06 UTC
Type: Bug

Attachments (Terms of Use)

Description Cesar Eduardo Barros 2013-10-22 09:46:10 UTC
As mentioned on bug 1019390 comment 13, some places use secp521r1.

It is a logical progression from suiteb (secp256r1 and secp384r1), so I would expect it to be a common choice.

Comment 1 Tom "spot" Callaway 2013-10-22 09:50:04 UTC
Note: "some places" means "some instances of postfix".

Comment 2 Cesar Eduardo Barros 2013-10-22 10:00:58 UTC
Another data point: I use a self-compiled nss-softokn (basically, I split it from the unmodified upstream source, instead of using the hobbled source, and set the correct environment variable to make it compile the ECC code).

With that, going to https://www.ssllabs.com/ssltest/viewMyClient.html shows that my Firefox browser is sending the following curves: secp256r1, secp384r1, secp521r1.

The other two curves are the suiteb curves, which AFAIK were enabled by bug 319901. Only secp521r1 is AFAIK missing. If Firefox is choosing this particular set of three curves, it is probable that many others have the same choice. For greater compatibility, it would be a good idea to enable at least these three curves.

Comment 3 Cesar Eduardo Barros 2013-10-22 10:06:40 UTC
And yet another data point: Qualys' SSL server tester (https://www.ssllabs.com/ssltest/) has hardcoded knowledge about a few common browsers (it can be seen at the results page after testing any SSL server). Looking at the latest version of what I would consider the most relevant browsers, I see:

Firefox 24 / Win 7: secp256r1, secp384r1, secp521r1
Chrome 30 / Win 7: secp256r1, secp384r1, secp521r1
IE 11 / Win 8.1: secp256r1, secp384r1

Comment 4 Hubert Kario 2013-11-01 10:09:03 UTC
According to ssllabs.com, IE on Win 7 also supports only secp256r1 and secp384r1 so sites that want to be compatible with Windows 7 and Windows 8 CryptoAPI can't use secp521r1.

Comment 5 Tomas Mraz 2013-11-01 10:22:37 UTC
That doesn't mean that openssl cannot support secp521r though. It just means that you can't have your server configured to support just secp521r if you want to be compatible with IE.

Comment 6 Cesar Eduardo Barros 2013-11-01 22:14:46 UTC
(In reply to Tomas Mraz from comment #5)
> That doesn't mean that openssl cannot support secp521r though. It just means
> that you can't have your server configured to support just secp521r if you
> want to be compatible with IE.

It means, however, that supporting secp521r1 isn't as high a priority.

I created these specific curve bugs because I believe the only curves most people are interested in are secp256r1, secp384r1, secp521r1, secp256k1, and curve25519/ed25519. The first two are already in, and the last one AFAIK is not on openssl yet. Having a separate bug for each curve reduces the noise in the global "enable ecc" bugs.

The postfix issue mentioned above might have been fixed by bug 1022493; see bug 1019390 comment 16. If that is true, that lowers the urgency for this curve; secp256k1 (bug 1021898) becomes the most urgent of the two.

Comment 7 Tomas Mraz 2013-11-01 22:29:50 UTC
We now have ACK from legal for the secp521r1 curve, not yet for the other curves.

Comment 8 Darren Tucker 2013-11-07 06:07:51 UTC
This also impacts the ecdsa-sha2-nistp521 SSH key exchange method (listed as REQUIRED in RFC5656).

Note You need to log in before you can comment on or make changes to this bug.