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.

EDIT:

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. –  owlstead Aug 24 '13 at 1:12

1 Answer 1

up vote 2 down vote accepted

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

Your Answer

 
discard

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.