The National Security Agency published this:
in which they say use to, for key exchange, "3072 bit RSA, DHE with 3072 bits, and/or ECDHE with p384" only.
If I'm understanding that paper (which I may not be as I'm skimming through it), they're specifically focusing on what the configuration should be for government/military systems.
The primary audiences for this guidance are National Security System (NSS), Department of Defense (DoD), and Defense Industrial Base (DIB) cybersecurity leaders, system administrators, and network security analysts.
My understanding is that 2048-bit RSA and 256-bit ECDHE are "roughly" equivalent in terms of difficulty to brute-force. If they're recommending going up to 3072-bit RSA, it'd make sense that they'd also suggest 384-bit ECDHE. I don't think it's anything specific to P-256 (at least, not that they'd admit), just that their requirements (for gov/mil systems) are for something higher, perhaps due to who they think might be attacking them.
It may also be the expected lifetime of the systems. I think they're hoping that it gets configured at a more secure level now so they don't need to get everybody to update again 5 to 10 years from now. It's probably similar logic to why the Let's Encrypt roots use 4096-bit RSA and P-384, since they're longer-lived systems and it's hard to predict the state of crypto a decade out.
I don't see anything specifically hinting at "We broke EC and don't use it" or the like, just that their requirements are for longer key lengths, though again I guess I could be misreading it.
4 Likes
Hi @9peppe!
NSA recommends that only TLS 1.2 or TLS 1.3 be used 3 ; and that SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 not be used
IMHO - Seems like old news to me and our government is only finally beginning to apply what we already know.... "It's a game of catch up".
Obviously there's more to the "guidance" than I am responding to. Thank you for posting it!
2 Likes
@Rip, they have to cover all angles - even the old ones.
That one hasn't changes in a while...
But read on - there's more too find!
Like this almost hidden gem:
@Osiris, I recall us having a recent conversation about x25519 and secp256r1.
3 Likes
@rg305 Why specifically are you pointing out section 5.1.1? I guess it is because I've never used custom parameters and do not fully understand the benefit of using that.
1 Like
Custom parameters give a marginal advantage, and opinions differ, but you should not use dhparams, custom or not: strongly prefer ECDHE to DHE.
2 Likes
But that's not what they did. They went and suggested a curve that's incredibly slow, incredibly unsupported by browsers. That's almost like saying "don't use ECDHE on .gov websites."
I have several curves configured on my webservers, including the NSA suggested one: "sect571r1, secp256k1, secp384r1, secp521r1, x448" and excluding the two common, safe but not safest "secp256r1, x25519" -- and this config is pretty strong according to ssllabs, aes >256 equivalent.
2 Likes
I set this in my apache config. Should I be better without or am I misunderstanding? This cert is generated by me.
SSLOpenSSLConfCmd DHParameters "/etc/ssl/private/dhparams_4096.pem"
1 Like
I think the main motivation here is quantum computing. The first real-world cryptographic protocols that will be broken by quantum computers (assuming you don't use something obviously bad) will probably be ones involving elliptic curves with 256 or less bits. For 384 bit curves, more QBits are needed, so it will take some more time until they get broken.
1 Like
That's fine, but it's not used very often. You can keep things as they are. Just check your cipher list and make sure to use ecdhe too.
2 Likes
I'm confused. I thought that secp384r1 and P-384 were two names for the same thing. For instance, ISRG Root X2's text dump says both names in it, one being an "ASN1" name and one being a "NIST" name. Or am I completely misunderstanding and they're referring to different parts of the encryption process and both are used? I'm far from an expert in all of this, just an amateur who knows that he knows just enough to be dangerous. I thought that this curve (the one Let's Encrypt uses for Root X2) was the one that NSA was recommending for elliptic curve based encryption, and that web browsers had reasonable support for it. It's just that P-256 is faster but has a shorter effective key length if I understand right.
2 Likes
(TL;DR: They're the same thing)
2 Likes
They pointed it out,
And are including it as part of their updated requirements.
Have a look at their recommendation for Apache here:
Mitigating-Obsolete-TLS/apache2-tls-cnsa.txt at master · nsacyber/Mitigating-Obsolete-TLS · GitHub
3 Likes
"Why is the NSA deprecating p256 ECDHE?"
Because governments move very slowly.
And I suppose they feel that within a year, or so, CPU power might make that seem... inadequate.
Security is a moving target.
If you stand still (long enough) you will be insecure.
5 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.