NSA Suite B Cryptography

[Steven M. Bellovin]

In message <434FCD37.1080601 at systemics.com>, Ian G writes:

>
>Which is to say, NSA solved its problem and it
>is nothing to do with FOSS.
>

Precisely.  NSA's actions here are independent of whether or not they 
like open source software on other criteria.  They've determined that 
ECC presents a better cost-benefit tradeoff.  We all understand, I 
think, why they're not enamored with 1024-bit RSA.  Doubling the key 
size means a ~8x performance hit for the signer and 4x for the 
verifier; they need to worry about embedded devices such as secure 
phones, sensors, and things like smart landmines.

Besides, they may feel that open source software isn't trustworthy 
enough to get near keys.  NSA isn't fond of software crypto to start 
with, though they're trying to adapt to it.  But they are very 
concerned about development methodology -- note the part about
'Testing, Evaluation and Certification of "Suite B" Products'.  (For
that matter, I'm also getting increasingly concerned about open source
development methodologies.  That, however, is a separate issue; if/when 
I write up something coherent, I'll post a pointer here.)

To me, the really interesting thing about that announcement was NSA's 
endorsement of certain algorithms and sizes.  It states that you can 
protect Top Secret traffic with 192-bit AES, 384-bit ECC DSA, and 
SHA-384.  Those numbers, especially the latter, are lower than I'd have 
guessed.  Note that the web page we're discussing is from Feb 2005, 
*after* Wang et al had successfully attacked MD5, though before the 
publication of their SHA-1 results.  NSA still has enough confidence in 
SHA-384 to rate it for Top Secret traffic.  I wonder what they're going 
to say at the Halloween Hash Bash....

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com