Following the recent government hacking (and subsequent news and fallout), I'm wondering what crypto-systems remain strong (and why) and what crypto-systems were exploited too heavily to be reliable. I'm wondering what will remain strong for the foreseeable future and why these systems were not affected (while the others presumably were).

I tried to find the information on the following and many other pages, but they were not very helpful in this case…

Perhaps someone can help me understand this.

  • 3
    $\begingroup$ Nothing has changed, really. You shouldn't use Dual_EC_DRBG, but then again, we've known you shouldn't use it since 2007. We know that certificate authorities are a weak link in the chain, but we've always known that. Snowden et al have said that one of the few defenses remaining is strong cryptography. $\endgroup$
    – Reid
    Commented Oct 14, 2013 at 22:48
  • $\begingroup$ @Reid I read something about SSL being exploited by them is that totally not accurate? Also, I read that elliptic curve and matrix-based crypto were considered very secure, and RSA and most of the other schemes remained. Was most of their hacking like at the application-level (like backdoors) or were they actually able to attack some of the cryptosystems? $\endgroup$
    – stackuser
    Commented Oct 14, 2013 at 22:53

2 Answers 2


NSA's own nuclear, military, navy, airforce and classified government networks are probably some of the most secure systems on the planet. They need to be extremely strong to protect the armed forces, government and populace. However the same cannot be said for their publicly recommended encryption systems because recent leaks have shown their intention is to backdoor/weaken those systems/standards that are in commercial/public use so they can use their surveillance network to monitor what everyone is doing. Their aim is totalitarian control and subversion of democracy.

They have not just been weakening one standard (Dual EC DBRG), they have been weakening a lot of them. You would be ill advised to continue using them. As of 2013-10-15 The Wikipedia link you gave provides a good list of those likely compromised systems to avoid. Until we know the full extent of the damage to cryptography in general it is better to lean on the side of caution. For starters that means avoiding any standard to do with NSA/NIST.

Standards with NSA involvement to avoid:

Suite B - set of cryptographic algorithms promulgated by the NSA as part of its Cryptographic Modernization Program

Advanced Encryption Standard (AES) - an encryption algorithm, selected by NIST after a public competition. In 2003, NSA certified AES for Type 1 use in some NSA-approved systems.

Secure Hash Algorithm - a widely used family of hash algorithms developed by NSA based on earlier designs by Ron Rivest.

Digital Signature Algorithm

Data Encryption Standard (DES)

Skipjack - the cipher developed for Clipper and finally published in 1998.

Clipper chip - a controversial failure that convinced NSA that it was advisable to stay out of the public arena.

Security-Enhanced Linux - not strictly an encryption system, but a recognition that in the 21st century, operating system improvements are vital to information security as well.

So what is left that is still good to use?

  • At the perfect security end you have got one-time pads and other cryptosystems that are information-theoretically secure. These are still in use by governments today. They transfer the one-time pads between embassies with diplomatic bags etc which are protected under the Vienna Convention.
  • After that you've got stream ciphers which attempt to mimic the one-time pad. These are likely still secure assuming you have a very long, quality random seed to begin with, an unbroken implementation and well designed CSPRNG. They do not offer perfect security however but would probably still frustrate the NSA.
  • After that there is independently designed block ciphers that should be ok to use for less important things e.g. hard disk encryption. For example, Serpent, Twofish, Threefish etc. Remember you want 256 bits or greater to take into effect recent developments in quantum computing and cryptanalytic breakthroughs.
  • Newer hashing algorithms not designed by NSA should be fine to use. Recent examples might be finalists in the recent NIST hash competition. Obviously steer clear of the finalised SHA-3 standard by NIST and use the original Keccak algorithm which has already been vetted by various cryptographers. You do not need NIST's "tweaks" that are being made to suit their purposes, not yours.
  • Elliptic curve cryptography is not my area of expertise. However if you are going that route avoid the NIST recommended curves and use some independently vetted ones.
  • Public key cryptography is fundamentally broken, especially with Certificate Authorities for authentication. The NSA only needs to compromise just one CA which is already trusted in your browser. Then they can silently MITM your connection and send you a false certificate signed by the same authority. Your browser will automatically accept it. Also because your web browser trusts over 500 different certificate authorities they can actually just send you a certificate signed by one of the compromised authorities and your browser will silently accept it and show a green padlock. Most users will not notice this. This is regardless of whether the real certificate was signed by that authority in the first place. Remember the certificates in your browser is like a keychain of all the people you trust. If there is just one bad apple then the whole trust system breaks down.

    Public key cryptography is a nice idea in theory, but it breaks down in the real world. In today's world with all the internet backbones tapped by "Five Eyes" countries and numerous untrusted router hops along the way, you do not actually have an authentic channel to transfer the public key to someone in the first place. In other words you have no idea if the public key you are receiving is actually the one you want to receive and not an attacker's. There is no provable authenticity. If you really wanted to use public key cryptography you would transfer the public key to them in person and load it into your keychain as trusted. That lets you know for sure that this is the real key and not an attacker's key. Potentially you could at least verify a checksum/hash of the key over another channel e.g. telephone. It is probably harder for an attacker to synthesize someone's voice in real-time. The CIA or MI6 could probably pull it off though.

  • $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$
    – e-sushi
    Commented Sep 12, 2017 at 14:25

We don't know what NSA (or any other spy agency--the US isn't the only country with code breakers) has broken. Other than Dual EC DRBG, we are left with everyone making their best guess, just like before. The NIST elliptic curves and the SHA2 hashes and DSA all came from NSA, but that seems to be the only real reason to suspect anything bad about them. Neither AES nor SHA3/Keccak have anything at all to do with NSA.

  • $\begingroup$ NIST is required by law to consult with the NSA on new encryption standards. And often these standards get unexplained alterations before they are finalized. Of course that doesn't indicate how much actual influence the NSA have on the process. It could just be a basic consultation, or they could manipulate the outcome (claiming there is a weakness in one of the standard they actually have difficulty with in order to push the decision to one they have an attack on), or they could be more active in manipulating the outcome. $\endgroup$ Commented Oct 28, 2013 at 10:16
  • $\begingroup$ Another example would be the IPSec standard. $\endgroup$ Commented Oct 28, 2013 at 10:25

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