21
$\begingroup$

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

$\endgroup$
  • $\begingroup$ 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. $\endgroup$ – Maarten Bodewes Aug 24 '13 at 1:12
  • $\begingroup$ May be related: crypto.stackexchange.com/questions/41193/… $\endgroup$ – DannyNiu Dec 5 '17 at 4:14
20
$\begingroup$

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

$\endgroup$
  • $\begingroup$ 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 ... $\endgroup$ – DeepSpace101 May 7 '15 at 3:28
11
$\begingroup$

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.

$\endgroup$
0
$\begingroup$

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

$\endgroup$
  • 1
    $\begingroup$ This begs the question of why they weren't interested in a 256-bit security level. $\endgroup$ – Gilles May 7 '15 at 19:42
  • 1
    $\begingroup$ that's because 192 is way more than enough: security.stackexchange.com/a/25392 $\endgroup$ – lily wilson May 10 '15 at 15:21
  • $\begingroup$ I wonder why you are linking to IANA and “RFC 5246 – The Transport Layer Security (TLS) Protocol Version 1.2, dated 2008”. After all, IANA has no (and never had) influence on decisions related to Suite B crypto – the NSA tends to handle decisions related to US national security all by itself… as “RFC 6460 – Suite B Profile for Transport Layer Security (TLS), dated January 2012” clearly shows. To learn more about the involved and enforced “Standards and Protocols” of Suite-B, please check nsa.gov/ia/programs/suiteb_cryptography $\endgroup$ – e-sushi Jun 19 '15 at 3:10
  • $\begingroup$ i didn't link to RFC 5246 at all. those cipher suites are defined in RFC 5289. the NSA often does take into consideration already existing implementations when making such decisions, and it's clear that that's the reason they chose AES 256 over AES 192. $\endgroup$ – lily wilson Jun 19 '15 at 3:38
  • $\begingroup$ @Gilles They may well be interested in 256-bit. But the NSA was giving guidelines about about key-sizes for different material classifications SECRET→128-bit. TOP SECRET→192-bit. But since there wasn't many good implementations of 192-bit, they bumped it up to 256-bit. But in reality 192-bit is good enough for TOP SECRET, and 256-bit is overkill. Presumably they can still have CODEWORD→256-bit. $\endgroup$ – Ian Boyd May 23 at 3:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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