Why is the P-521 elliptic curve not in Suite B if AES-256 is?

Question

In the NSA's document, "The Case for Elliptic Curve Cryptography" (archived), 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 TOP SECRET); however, the ECC is limited to P-384:

AES with 128-bit keys provides adequate protection for classified information up to the SECRET level. Similarly, ECDH and ECDSA using the 256-bit prime modulus elliptic curve as specified in FIPS PUB 186-3 and SHA-256 provide adequate protection for classified information up to the SECRET level.

AES with 256-bit keys, Elliptic Curve Public Key Cryptography using the 384-bit prime modulus elliptic curve as specified in FIPS PUB 186-3 and SHA-384 are required to protect classified information at the TOP SECRET level.

Despite P-521 being officially codified in NIST FIPS-186-4, an entropic choke point appears to have been introduced, as if we have a cryptographic "pipeline".

Example: If we're doing ECDH with P-384 keys and then use AES-256 to 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 unable to put these seemingly contradictory pieces of information together, so I thought I'd ask other people here. Why was P-521 excluded? Was it technical or non-technical? Any additional info would be appreciated.

EDIT:

This is not very directly related, but I checked some empirical testing results. Seems computation 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 again, AES-192 should have also sufficed...

Answer 1

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.)

Answer 2

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.

Answer 3

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:

https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4