Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

In the NSA's document, "The Case for Elliptic Curve Cryptography", we have

| Symmetric Key | RSA and Diffie-Hellman  | Elliptic Curve  |
| Size (bits)   |      Key Size (bits)    | Key Size (bits) |
|       80      |            1024         |       160       |
|      112      |            2048         |       224       |
|      128      |            3072         |       256       |
|      192      |            7680         |       384       |
|      256      |           15360         |       521       |
             Table 1: NIST Recommended Key Sizes

In NSA Suite B, we do have AES-256 (for TS), however the the ECC is limited to P-384, despite P-521 officially codified in NIST FIPS-186-4. This appears to introduce an entropic choke point if we're have a cryptographic "pipeline".

Example: If we're doing ECDH off P-384 keys to then AES-256 encrypt, we're effectively passing just 192 bits of keying entropy into the AES-256 engine.

Reading the only known response (that I know) on this IETF thread, the statement reads

Regarding NSA's omission of P-521, P-256 and P-384 will satisfy all of the U.S. Government's requirements so only these are included in Suite B. We don't have a requirement that warrants the inclusion of P-521.

I'm not able to piece these seemingly contradictory pieces of data, so I thought I'd ask other here. Why was P-521 excluded? Is it technical or non-technical? Additional info would be appreciated.


Not very directly related but I checked some empirical testing results. Seems compute times roughly double going from P-256 => P-386 => P-521, for almost any EC operation. Take for example signing a short (1200 bytes) message.

P-256:  8ms ( 64 byte signature) 
P-384: 15ms ( 96 byte signature)
P-521: 30ms (132 byte signature)

It's not directly representative of the entropic bottleneck above, more aligned towards the "good enough" line of thought. But then, AES-192 should have also sufficed...

share|improve this question
OK, so you found out that there is indeed a linear relation between computation time and ECC key size. This is a well known property of ECC and one of the reasons why ECC may be more future proof than e.g. RSA. Note that it is not possible for us to look into the mind of those generating the documents. The only thing I can tell is that e.g. the brainpool curves use a well defined set of domain parameters for a keysize of 512 bits. In general it is easier to handle data types that are a power of two and a multiple of 8. –  Maarten Bodewes Aug 24 '13 at 1:12

3 Answers 3

up vote 5 down vote accepted

The real question isn't "Why doesn't Suite B use P-521?" It is, "Why doesn't Suite B use AES-192?" NSA were only interested in 192-bit security for Suite B, but they chose to use AES-256 because AES-192 wasn't widely supported.

"In fact we had wanted to use AES -128 and AES-192, but a quick survey of AES implementations (hardware centric, I believe) showed that there were very few implemented AES-192, whence the decision to go with AES-128 and AES-256 in Suite B, paired with P256 and P384. All of the crypt purists grumbled endlessly about the mismatch betwixt AES-256 and P384."

-- Kevin M. Igoe, NSA

(I am choosing to take his explanation at face value, but you never know with intelligence agencies.)

share|improve this answer
Makes sense, thanks for the reference. Although by the timing Kevin might put me in the crypto purist group, I excuse myself from it as a crypto pragmatist. The question comes to (my) mind less as grumbling but more as a crypto anomaly design curiosity ... –  DeepSpace101 May 7 at 3:28

Since the rationale for the exclusion of P-521 and AES-192 is not explained, you can assume that either the curve is "too good" or that the cipher is "not good enough". The exclusion of SHA-512 implies a limit to 192-bit security for the standard, so AES-192 would be the logical choice. Its exclusion implies it is in someway not adequate for protecting TOP SECRET information at the given key length according the the NSA requirements for S3B.

The most logical answer is that S3B only requires a maximum of 192-bit security, and they are simply using AES-256 because of the increased round count over AES-192 or the difference in key schedule alignment. It has been argued by some over the years that AES has too low a round count for its given key lengths, so this makes sense from a security perspective. AES-256 only has a 40% increase in rounds for a 100% increase in keylength over AES-128, if I was writing the standard I may have made the same decision to skip AES-192.

S3A algorithms are classified, but most likely require 256-bit security and up, with higher standards for long term protection against cryptanalysis by well funded attackers (100+ years of security from China and Russia), and as such may skip AES all together and go to either variants with different round counts and key schedules, or use purpose built algorithms that do not have the same speed/security tradeoff that AES has.

share|improve this answer

they didn't include P-521, because they wanted a 192-bit security level and P-384 provides that.

the reason they didn't use AES-192 probably has something to do with the fact that AES-192 isn't in TLS:


share|improve this answer
This begs the question of why they weren't interested in a 256-bit security level. –  Gilles May 7 at 19:42
that's because 192 is way more than enough: security.stackexchange.com/a/25392 –  lily wilson May 10 at 15:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.