5 ms·

Speaking of Zero Trust and the NSA, isn't the NSA the agency that published the weak Elliptic Curve Cryptography constant that allowed a backdoor into SSL encry

Speaking of Zero Trust and the NSA, isn't the NSA the agency that published the weak Elliptic Curve Cryptography constant that allowed a backdoor into SSL encryption?

moonchild 6y ago
Yes, because they don't trust anybody else to have strong cryptography. Perfectly consistent.
- pdkl95 6y ago
  The NSA calls this type of power asymmetry "NOBUS" ("nobody but us"). https://en.wikipedia.org/wiki/NOBUS https://en.wikipedia.org/wiki/NOBUS https://www.schneier.com/essays/archives/2017/05/why_the_nsa_makes_us.html https://www.schneier.com/essays/archives/2017/05/why_the_nsa...
tialaramex 6y ago
> isn't the NSA the agency that published the weak Elliptic Curve Cryptography constant that allowed a backdoor into SSL encryption? Assuming what you meant is closer to "Don't I remember something to do with elliptic curves, and the NSA and an SSL backdoor?" then sure, you do remember that confluence of topics. The NSA proposed Dual_EC_DRBG which is a cryptographically secure random number generator with weird properties, it successfully had Dual_EC_DRBG included in the NIST standard and in RSA (the company not the cryptography) BSAFE around 2004 or so. Dual_EC_DRBG is clearly worse than the existing state of the art as a random number generator - the numbers aren't as random as you'd like, but it also possesses a potential backdoor. If the designers chose to do so they could pick values such that they know a secret they can use to find out your seed values from your output. The NSA's Dual_EC_DRBG does not explain how it picked the values used. In cryptography it's usual to pick "Nothing Up My Sleeve" numbers, such as decimal digits from Pi when constants are necessary and you want to show that you have no nefarious motive for picking the ones used. This was not done for Dual_EC_DRBG. The New York Times claims to have (but has never shown anybody) smoking gun evidence that the NSA deliberately picked values allowing them a backdoor. Even without that evidence, we know this type of algorithm would be vulnerable to such things and we know it's not otherwise better than what we have, so it's weird they wanted people to use it. If participants used Dual_EC_DRBG as their only or main source of randomness, then yes it's likely that the NSA knows the backdoor and could get back their seed values and thus get back the ephemeral secret keys they are using for SSL/TLS.
- KMag 6y ago
  There is some weak reasoning with Dual_EC_DRBG ... ignoring the possibility of power/timing/etc. side-channels, Dual_EC_DRBG is as provably difficult to break as Elliptic Curve Diffie-Hellman and at least as strong as ECDSA using the same curve. If your system is already broken if the attacker can compute discrete logs over that particular elliptic curve, and you trust that the NSA didn't generate the two constants in Dual_EC_DRBG such that they know the scalar to multiply the one by to get the other... then using Dual_EC_DRBG doesn't introduce extra attack surface, while using another PRNG does introduce extra attack surface. Now, that's weak reasoning, particularly since they only dropped 16 bits when outputting values where it seems much safer to drop half the bits when outputting a value. However, there is a narrow set of circumstances where Dual_EC_DRBG makes sense. Also, if you're using ECDH for encryption, you're almost certainly using AES in counter mode or ChaCha20. In that case, you're best off using a PRNG based on AES in counter mode or ChaCha20, using an entropy-gathering seeding algorithm that gracefully recovers from state compromise (such as Fortuna).
- jiggawatts 6y ago
  It's absolutely certain that Dual_EC_DRBG was used as an NSA back door. The NSA went out of their way to force it into a bunch of products, which is weird enough. Many "experts" dismissed the risk, because they claimed that the only real "danger" was that if the internal state of the RNG were to leak out over the wire, it would be trivial for the NSA (given their private key) to crack encryption of VPNs. No leak, no risk. Juniper had a vulnerability in their VPN products. That little fiasco involved Chinese hackers having replaced the Dual_EC_DRBG public key with their own backdoored public key! When that was disclosed many security researchers suddenly took a keen interest in the Juniper VPN code and discovered that it "accidentally" leaked just the right number of bytes of RNG state into the initial connection packets. Look. Just... sigh. If you're outside of the United States and you purchase any security product made by a US company, just assume that device has an NSA back door and is being used to spy on you. Juniper VPNs definitely were. Similar VPN products from Cisco most likely were. RSA hardware tokens had an insane design where they used a "tree" of keys where RSA had a root key to could be used to emulate any key fob. Three guesses as to why they needed to do that instead of simply generating standalone unrelated key pairs per fob? Similarly, anything you store on Azure, AWS, Office 365 or G Suite should be considered compromised by the US. Encryption my ass. They have a copy of your encryption key!
pyinstallwoes 6y ago
And the history of even having to get approval to publish code with encryption...

Speaking of Zero Trust and the NSA, isn't the NSA the agency that published the weak Elliptic Curve Cryptography constant that allowed a backdoor into SSL encryption?

moonchild 6y ago

Yes, because they don't trust anybody else to have strong cryptography. Perfectly consistent.

pdkl95 6y ago
The NSA calls this type of power asymmetry "NOBUS" ("nobody but us"). https://en.wikipedia.org/wiki/NOBUS https://en.wikipedia.org/wiki/NOBUS https://www.schneier.com/essays/archives/2017/05/why_the_nsa_makes_us.html https://www.schneier.com/essays/archives/2017/05/why_the_nsa...

tialaramex 6y ago

> isn't the NSA the agency that published the weak Elliptic Curve Cryptography constant that allowed a backdoor into SSL encryption? Assuming what you meant is closer to "Don't I remember something to do with elliptic curves, and the NSA and an SSL backdoor?" then sure, you do remember that confluence of topics. The NSA proposed Dual_EC_DRBG which is a cryptographically secure random number generator with weird properties, it successfully had Dual_EC_DRBG included in the NIST standard and in RSA (the company not the cryptography) BSAFE around 2004 or so. Dual_EC_DRBG is clearly worse than the existing state of the art as a random number generator - the numbers aren't as random as you'd like, but it also possesses a potential backdoor. If the designers chose to do so they could pick values such that they know a secret they can use to find out your seed values from your output. The NSA's Dual_EC_DRBG does not explain how it picked the values used. In cryptography it's usual to pick "Nothing Up My Sleeve" numbers, such as decimal digits from Pi when constants are necessary and you want to show that you have no nefarious motive for picking the ones used. This was not done for Dual_EC_DRBG. The New York Times claims to have (but has never shown anybody) smoking gun evidence that the NSA deliberately picked values allowing them a backdoor. Even without that evidence, we know this type of algorithm would be vulnerable to such things and we know it's not otherwise better than what we have, so it's weird they wanted people to use it. If participants used Dual_EC_DRBG as their only or main source of randomness, then yes it's likely that the NSA knows the backdoor and could get back their seed values and thus get back the ephemeral secret keys they are using for SSL/TLS.

KMag 6y ago
There is some weak reasoning with Dual_EC_DRBG ... ignoring the possibility of power/timing/etc. side-channels, Dual_EC_DRBG is as provably difficult to break as Elliptic Curve Diffie-Hellman and at least as strong as ECDSA using the same curve. If your system is already broken if the attacker can compute discrete logs over that particular elliptic curve, and you trust that the NSA didn't generate the two constants in Dual_EC_DRBG such that they know the scalar to multiply the one by to get the other... then using Dual_EC_DRBG doesn't introduce extra attack surface, while using another PRNG does introduce extra attack surface. Now, that's weak reasoning, particularly since they only dropped 16 bits when outputting values where it seems much safer to drop half the bits when outputting a value. However, there is a narrow set of circumstances where Dual_EC_DRBG makes sense. Also, if you're using ECDH for encryption, you're almost certainly using AES in counter mode or ChaCha20. In that case, you're best off using a PRNG based on AES in counter mode or ChaCha20, using an entropy-gathering seeding algorithm that gracefully recovers from state compromise (such as Fortuna).
jiggawatts 6y ago
It's absolutely certain that Dual_EC_DRBG was used as an NSA back door. The NSA went out of their way to force it into a bunch of products, which is weird enough. Many "experts" dismissed the risk, because they claimed that the only real "danger" was that if the internal state of the RNG were to leak out over the wire, it would be trivial for the NSA (given their private key) to crack encryption of VPNs. No leak, no risk. Juniper had a vulnerability in their VPN products. That little fiasco involved Chinese hackers having replaced the Dual_EC_DRBG public key with their own backdoored public key! When that was disclosed many security researchers suddenly took a keen interest in the Juniper VPN code and discovered that it "accidentally" leaked just the right number of bytes of RNG state into the initial connection packets. Look. Just... sigh. If you're outside of the United States and you purchase any security product made by a US company, just assume that device has an NSA back door and is being used to spy on you. Juniper VPNs definitely were. Similar VPN products from Cisco most likely were. RSA hardware tokens had an insane design where they used a "tree" of keys where RSA had a root key to could be used to emulate any key fob. Three guesses as to why they needed to do that instead of simply generating standalone unrelated key pairs per fob? Similarly, anything you store on Azure, AWS, Office 365 or G Suite should be considered compromised by the US. Encryption my ass. They have a copy of your encryption key!

pyinstallwoes 6y ago

And the history of even having to get approval to publish code with encryption...