8 ms·

RSA warns developers not to use RSA products

132 points by pedro84 13y ago

devx 13y ago
The RSA CTO's answers are hilarious. He can't really be that clueless as the CTO of a security firm, can he? That would be incredibly embarrassing in itself (which it already is), but the alternative is even worse (choosing the one with the backdoor on purpose).
- anaphor 13y ago
  Especially the part about KDFs being deliberately slow, and according to him that somehow implies that RNGs should also be slow. Whut? This guy is really a CTO?
  - tlb 13y ago
    "The length of time that Dual_EC_DRBG takes can be seen as a virtue: it also slows down an attacker trying to guess the seed." If a system's seed is weak, one attack is to try all likely seeds, run them through the PRNG to generate keys, and see if any of the keys work. A slow PRNG indeed slows down this process. For instance, it would have slowed down the attack on the Taiwan Cryptocards, which exploited patterns in the seed that appear directly in the key, reported here: http://smartfacts.cr.yp.to/smartfacts-20130916.pdf http://smartfacts.cr.yp.to/smartfacts-20130916.pdf
    - matthewdgreen 13y ago
      That's a really poor idea. If you're concerned about guessing attacks on your RNG seed, the right response is to increase the size of your seed -- NOT to slow down the function. To put it another way, adding one bit to the seed length is equivalent to doubling the cost of the attack. In other words, a 1000x slowdown in the generator is the same as about 10 bits of additional seed material. Not worth it!
    - marshray 13y ago
      No, it wouldn't have slowed the attack on the Taiwan Cryptocards one bit. That and the related "Mining Your P's and Q's" research involved deriving the private keys from the public keys using bulk factorization. They did not need to simulate the operation of the poorly-seeded PRNG that generated them.
      - tlb 13y ago
        They got the first 103 keys with batch GCD. After that, they found many more keys by looking at patterns in the keys and doing trial division by keys that were similar to the patterns. A better PRNG would make that harder (to reverse-engineer the patterns in the seed) and a slower PRNG makes it slower.
        marshray 13y ago
        A better (i.e., not completely utterly horribly broken) PRNG would have made it impossible to observe and associate patterns in the output, even with poorly seeded entropy. There's no reason such a PRNG needs to be any slower than a fast cipher or hash function such as AES or SHA-2.
    - jpgoldberg 13y ago
      I've been a big advocate of things like PBKDF2 and such to slow things down where appropriate. But except for very specialized circumstances (and an RNG isn't one of them), we want cryptographic operations to be fast. In general, we want RNGs (and most things) to be fast and efficient. And in particular, TW Cryptocards analysis never had to run the RNG. Just had to look at 2 million public keys already out there.
- derefr 13y ago
  His answers are post-hoc justifications. The real reason they picked it was because they wanted to make money on sweet, sweet government contracts, and the easiest way to do that is to just do everything NIST says to the letter.
  - yuhong 13y ago
    http://lists.randombit.net/pipermail/cryptography/2013-September/005341.html http://lists.randombit.net/pipermail/cryptography/2013-Septe...
    - deleted 13y ago
      [deleted]
- JamesBarrows 13y ago
  You're assuming that the CTO is technically competent. I've found over the years that even CTO's who once were technically competent either get lobotomy's, or suffer from hypoxia from the low oxygen at the summit of major corps. Or, management exists cover up bad hiring practices. Take your pick. Either way, CTO's saying dumb things seems to be normal.
- thrownaway2424 13y ago
  I think it's probably very easy to rise into the upper levels of management at EMC while being a complete moron.
- busterarm 13y ago
  We still don't know who at RSA opened the spreadsheet that carried the malware behind the SecurID breach. Seems like we've got a reasonable guess now though.
- smsm42 13y ago
  He's in a tricky position. Imagine somebody in RSA taking decision years ago to follow "strong suggestion" of NSA, accompanied by millions of dollars, to choose certain algorithm as the default. Now current CTO has a choice: 1. say "we deliberately built the backdoor into our software, please never buy our products again if you value your security" and go live the rest of his life in a Buddhist monastery in Tibet, 2. say some embarrassing BS which gives him a veil of plausible deniability while raising doubts of his personal competency, but who cares, he's a C-type, they don't have to know all the details, right?
lawnchair_larry 13y ago
Hasn't tptacek posted "nothing to see here" regarding this issue on HN a half dozen times because "nobody uses it"? :)
- jgon 13y ago
  This was actually going to be the first thing I posted when I read this link. tptacek repeatedly assured everyone that this was absolutely not a big deal and meant nothing because nobody in their right mind uses the standard. Except whoops, one of, if not the, largest players in the field. I'm sure he'll have a bunch of really great replies that manage to simultaneously say why this still isn't a big deal and passive-aggresively insult our knowledge of the situation. I look forward to reading what he has to say.
  - MisterWebz 13y ago
    He's been trying to downplay the importance of the leaks since it first started, so what did you expect.
    - drivebyacct2 13y ago
      Both he and other big wig top-posters here on HN, though they've crept back into the shadows more than tptacek.
    - deleted 13y ago
      [deleted]
  - icelancer 13y ago
    I don't understand his constant line in the sand on this issue (amongst other things). You basically illustrated exactly how he structures his arguments on this topic.
    - tptacek 13y ago
      If I was smart enough to understand what this comment meant, I'd respond to it. Maybe you could clarify? I can't find a way to reconcile it with its parent comment in a way that gives me anything to discuss.
ChrisAntaki 13y ago
>> So why would RSA pick Dual_EC as the default? You got me. Not only is Dual_EC hilariously slow Because the NSA didn't just backdoor the Dual_EC standard. It backdoored the technology industry, as well as the rule of law.
pepve 13y ago
It irks me that many people are calling this a backdoor. It's not. It's a vulnerability. You have to exploit it to get in.
- pedrocr 13y ago
  How do you figure? The scandal around the NSA PRNG is indeed a backdoor, is it not?
- tel 13y ago
  Serious question: what's the difference? I would have followed the definition for backdoor since it relies on particular secret information relating P and Q that the NSA might have—but where should one draw the line between backdoors and vulnerabilities? Intent?
  - meowface 13y ago
    Repeating my comment: An intentionally introduced vulnerability can be considered a backdoor, even if it's not a matter of saying "open sesame" to open the so-called backdoor. So yes, it's pretty much a matter of intent.
  - ballard 13y ago
    Nerd's law: A commenter C declares that concepts X and Y are completely different. Because parent commenter P failed to make this point, P is intellectually inferior to C. Hence C > P for all X and Y.
- nullc 13y ago
  It's a PRNG based on a trapdoor function where apparently the NSA has the key. With that key they can recover the RNG state from just a small amount of it. Thats a backdoor by most descriptions. This isn't just a bug.
  - piratebroadcast 13y ago
    Snowden obviously has that key as well.
deleted 13y ago
[deleted]
- ReidZB 13y ago
  I'm not sure exactly what you're talking about. When the initial constants for Dual_EC_DRBG were generated, the NSA had the opportunity to generate them in such a way that they would be able to predict all future outputs after observing just a few bytes of output. I don't see how this (1) doesn't qualify as a potential back door and (2) means that the NSA 'could not' insert a back door. The back door here is the knowledge of the 'secret key' that they could know (by virtue of the constant generation). Of course, it's just an alleged back door here; we don't know the truth. By the way, the 'less-than-technically-competent journalist' here is Matthew Green, a cryptographer. So I think he's plenty technically-competent. Also, they're called elliptic curves, not 'elliptical' curves.
- meowface 13y ago
  Actually, you very well can (try to) backdoor any kind of cryptographic algorithm. A hashing algorithm, an encryption algorithm, or a PRNG algorithm. Read this article in full to understand just how it works: http://blog.cryptographyengineering.com/2013/09/the-many-flaws-of-dualecdrbg.html http://blog.cryptographyengineering.com/2013/09/the-many-fla... Now of course, can you do it in a way that not even a veteran cryptographer could ever notice it? Pretty unlikely.
- ballard 13y ago
  Then feel free to question Schneier's chops: http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115 http://www.wired.com/politics/security/commentary/securityma... Edit: this was in response to the deleted comment
  - tptacek 13y ago
    I'll take you up on that. Here's Schneier on ECC: https://www.schneier.com/crypto-gram-9911.html#EllipticCurvePublic-KeyCryptography https://www.schneier.com/crypto-gram-9911.html#EllipticCurve... He wrote this in 1999; ECC was at the time sort of a novelty, it's headline being "a way to do cryptography with smaller key sizes", as if ECC was mostly a way to fit crypto into smaller memory software. Schneier and Ferguson wrote _Practical Cryptography_ in 2003. It has virtually no mention whatsoever of ECC cryptography, despite ECC's already significantly increased importance by then. In 2013, I think it's fair to say that the balance of expert opinion on ECC vs. RSA is sharply against Schneier's take on ECC. RSA is on the way out, and ECC is what's going to replace it. Equally significantly, crypto constructions that use signing and key agreement but not public-key encryption/decryption operations are modern designs; designs where a long-lived RSA key is used to wrap and unwrap secrets are dated. ECC is useful for the modern constructions and less so for the dated ones. I don't think Schneier's writing has tracked these shifts well. I think his books are very light on, for instance, forward secrecy or deterministic signing. His research results never focused on public key encryption and never touched ECC (it's worth noting that much of his best known research was also done with John Kelsey, who is at NIST --- coincidentally, one of Schneier's best-known designs, with Kelsey, was the Yarrow CSPRNG). Also: Schneier has a close working relationship with Niels Ferguson, who was one of the researchers that spotted the weirdness in Dual_EC. So it's possible that Schneier's concerns over the "constants" in ECC all stem from that. (It's hard to say; he could also be referring to the random seed in the P-224 and P-256 curves). I don't think readers have any particular reason to believe that Bruce Schneier is an authority on ECC. Cryptography is not one topic. It's actually a little silly to suggest anyone like Schneier could be authoritative on all crypto concepts. Look at the research output of famous cryptographic researchers (Schneier has some research, but is not really a top-tier researcher) --- it tends to specialize!
intelliot 13y ago
reminds me of the State Science Institute
SimHacker 13y ago
Would you trust a computer security company who didn't hash the passwords of their users on their web site, and instead stored the plain text passwords encrypted in their database, with the keys to decrypt them on their server, because they claim that "Your data are encrypted on our server, if you request the password to be sent to you by email the system knows how to decrypt the information and it will send you the Email. This is for customer convenience as many customer do not wish their password to be reset each time they have a problem." Would you trust a computer security company that when you reset your password on their web site, sent you a new password that was literally the same as your email address that you signed in with? If this company sold closed source encryption software, would you trust that the software was competently written and did not have back doors, if the president of the company defended their actions of not hashing passwords, and of resetting passwords to their user's email addresses? What if the president of that company had been prosecuted for computer crimes in the past, and had spend time in jail for it, because after he was first caught, he went right back to phone freaking again and got caught again? Would you trust the president of the company, who is a convicted felon, who fraudulently made a lot of money by computer crime and got caught, but had most of the charges dropped and his sentence reduced, not to have made a deal with the government and promise to return their favor of giving him a more lenient sentence in exchange for certain favors in the future? Can anyone guess who I'm referring to?
- SimHacker 13y ago
  I'll give you some more hints: His company came out with a "secure" voice encryption product, and then a previously unknown anonymous hacker reviewed the product and its competitors, and wrote a suspiciously positive review of it, claiming it was the only one he couldn't break. His company then published a press release trumpeting the favorable review, right before a big mobile security conference. A suspicious security researcher baited the anonymous hacker to post on his blog, and it turned out he was using an ip addressed registered to the security company whose product he'd written a favorable review about. When confronted with proof, the founder of the security company denied astroturfing, denied knowing the hacker, and implausibly claimed the anonymous hacker must have been using his company's anonymous browsing service. The same security company founder who spent three years in jail for phone phreaking, because he was convicting of hacking and defrauding profit. The same security company who stores their user's passwords in unhashed unsalted plain text encrypted with a key on their server. The same security company who resets their user's passwords with their email address. The same security company whose founder claims that "many customer do not wish their password to be reset each time they have a problem" justifies not hashing passwords, and resetting passwords to "convenient" email addresses. The same security company whose founder refuses to change his "unconventional" security policies after being confronted with these facts, and instead makes ridiculous excuses for his incompetence, and continues to betray the trust of his customers even after he's been confronted with it. Can you figure out who it is now?

132 points by pedro84 13y ago

devx 13y ago

The RSA CTO's answers are hilarious. He can't really be that clueless as the CTO of a security firm, can he? That would be incredibly embarrassing in itself (which it already is), but the alternative is even worse (choosing the one with the backdoor on purpose).

anaphor 13y ago
Especially the part about KDFs being deliberately slow, and according to him that somehow implies that RNGs should also be slow. Whut? This guy is really a CTO?
- tlb 13y ago
  "The length of time that Dual_EC_DRBG takes can be seen as a virtue: it also slows down an attacker trying to guess the seed." If a system's seed is weak, one attack is to try all likely seeds, run them through the PRNG to generate keys, and see if any of the keys work. A slow PRNG indeed slows down this process. For instance, it would have slowed down the attack on the Taiwan Cryptocards, which exploited patterns in the seed that appear directly in the key, reported here: http://smartfacts.cr.yp.to/smartfacts-20130916.pdf http://smartfacts.cr.yp.to/smartfacts-20130916.pdf
  - matthewdgreen 13y ago
    That's a really poor idea. If you're concerned about guessing attacks on your RNG seed, the right response is to increase the size of your seed -- NOT to slow down the function. To put it another way, adding one bit to the seed length is equivalent to doubling the cost of the attack. In other words, a 1000x slowdown in the generator is the same as about 10 bits of additional seed material. Not worth it!
  - marshray 13y ago
    No, it wouldn't have slowed the attack on the Taiwan Cryptocards one bit. That and the related "Mining Your P's and Q's" research involved deriving the private keys from the public keys using bulk factorization. They did not need to simulate the operation of the poorly-seeded PRNG that generated them.
    - tlb 13y ago
      They got the first 103 keys with batch GCD. After that, they found many more keys by looking at patterns in the keys and doing trial division by keys that were similar to the patterns. A better PRNG would make that harder (to reverse-engineer the patterns in the seed) and a slower PRNG makes it slower.
      - marshray 13y ago
        A better (i.e., not completely utterly horribly broken) PRNG would have made it impossible to observe and associate patterns in the output, even with poorly seeded entropy. There's no reason such a PRNG needs to be any slower than a fast cipher or hash function such as AES or SHA-2.
  - jpgoldberg 13y ago
    I've been a big advocate of things like PBKDF2 and such to slow things down where appropriate. But except for very specialized circumstances (and an RNG isn't one of them), we want cryptographic operations to be fast. In general, we want RNGs (and most things) to be fast and efficient. And in particular, TW Cryptocards analysis never had to run the RNG. Just had to look at 2 million public keys already out there.
derefr 13y ago
His answers are post-hoc justifications. The real reason they picked it was because they wanted to make money on sweet, sweet government contracts, and the easiest way to do that is to just do everything NIST says to the letter.
- yuhong 13y ago
  http://lists.randombit.net/pipermail/cryptography/2013-September/005341.html http://lists.randombit.net/pipermail/cryptography/2013-Septe...
  - deleted 13y ago
    [deleted]
JamesBarrows 13y ago
You're assuming that the CTO is technically competent. I've found over the years that even CTO's who once were technically competent either get lobotomy's, or suffer from hypoxia from the low oxygen at the summit of major corps. Or, management exists cover up bad hiring practices. Take your pick. Either way, CTO's saying dumb things seems to be normal.
thrownaway2424 13y ago
I think it's probably very easy to rise into the upper levels of management at EMC while being a complete moron.
busterarm 13y ago
We still don't know who at RSA opened the spreadsheet that carried the malware behind the SecurID breach. Seems like we've got a reasonable guess now though.
smsm42 13y ago
He's in a tricky position. Imagine somebody in RSA taking decision years ago to follow "strong suggestion" of NSA, accompanied by millions of dollars, to choose certain algorithm as the default. Now current CTO has a choice: 1. say "we deliberately built the backdoor into our software, please never buy our products again if you value your security" and go live the rest of his life in a Buddhist monastery in Tibet, 2. say some embarrassing BS which gives him a veil of plausible deniability while raising doubts of his personal competency, but who cares, he's a C-type, they don't have to know all the details, right?

lawnchair_larry 13y ago

Hasn't tptacek posted "nothing to see here" regarding this issue on HN a half dozen times because "nobody uses it"? :)

jgon 13y ago
This was actually going to be the first thing I posted when I read this link. tptacek repeatedly assured everyone that this was absolutely not a big deal and meant nothing because nobody in their right mind uses the standard. Except whoops, one of, if not the, largest players in the field. I'm sure he'll have a bunch of really great replies that manage to simultaneously say why this still isn't a big deal and passive-aggresively insult our knowledge of the situation. I look forward to reading what he has to say.
- MisterWebz 13y ago
  He's been trying to downplay the importance of the leaks since it first started, so what did you expect.
  - drivebyacct2 13y ago
    Both he and other big wig top-posters here on HN, though they've crept back into the shadows more than tptacek.
  - deleted 13y ago
    [deleted]
- icelancer 13y ago
  I don't understand his constant line in the sand on this issue (amongst other things). You basically illustrated exactly how he structures his arguments on this topic.
  - tptacek 13y ago
    If I was smart enough to understand what this comment meant, I'd respond to it. Maybe you could clarify? I can't find a way to reconcile it with its parent comment in a way that gives me anything to discuss.

ChrisAntaki 13y ago

>> So why would RSA pick Dual_EC as the default? You got me. Not only is Dual_EC hilariously slow Because the NSA didn't just backdoor the Dual_EC standard. It backdoored the technology industry, as well as the rule of law.

pepve 13y ago

It irks me that many people are calling this a backdoor. It's not. It's a vulnerability. You have to exploit it to get in.

pedrocr 13y ago
How do you figure? The scandal around the NSA PRNG is indeed a backdoor, is it not?
tel 13y ago
Serious question: what's the difference? I would have followed the definition for backdoor since it relies on particular secret information relating P and Q that the NSA might have—but where should one draw the line between backdoors and vulnerabilities? Intent?
- meowface 13y ago
  Repeating my comment: An intentionally introduced vulnerability can be considered a backdoor, even if it's not a matter of saying "open sesame" to open the so-called backdoor. So yes, it's pretty much a matter of intent.
- ballard 13y ago
  Nerd's law: A commenter C declares that concepts X and Y are completely different. Because parent commenter P failed to make this point, P is intellectually inferior to C. Hence C > P for all X and Y.
nullc 13y ago
It's a PRNG based on a trapdoor function where apparently the NSA has the key. With that key they can recover the RNG state from just a small amount of it. Thats a backdoor by most descriptions. This isn't just a bug.
- piratebroadcast 13y ago
  Snowden obviously has that key as well.

deleted 13y ago

[deleted]

ReidZB 13y ago
I'm not sure exactly what you're talking about. When the initial constants for Dual_EC_DRBG were generated, the NSA had the opportunity to generate them in such a way that they would be able to predict all future outputs after observing just a few bytes of output. I don't see how this (1) doesn't qualify as a potential back door and (2) means that the NSA 'could not' insert a back door. The back door here is the knowledge of the 'secret key' that they could know (by virtue of the constant generation). Of course, it's just an alleged back door here; we don't know the truth. By the way, the 'less-than-technically-competent journalist' here is Matthew Green, a cryptographer. So I think he's plenty technically-competent. Also, they're called elliptic curves, not 'elliptical' curves.
meowface 13y ago
Actually, you very well can (try to) backdoor any kind of cryptographic algorithm. A hashing algorithm, an encryption algorithm, or a PRNG algorithm. Read this article in full to understand just how it works: http://blog.cryptographyengineering.com/2013/09/the-many-flaws-of-dualecdrbg.html http://blog.cryptographyengineering.com/2013/09/the-many-fla... Now of course, can you do it in a way that not even a veteran cryptographer could ever notice it? Pretty unlikely.
ballard 13y ago
Then feel free to question Schneier's chops: http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115 http://www.wired.com/politics/security/commentary/securityma... Edit: this was in response to the deleted comment
- tptacek 13y ago
  I'll take you up on that. Here's Schneier on ECC: https://www.schneier.com/crypto-gram-9911.html#EllipticCurvePublic-KeyCryptography https://www.schneier.com/crypto-gram-9911.html#EllipticCurve... He wrote this in 1999; ECC was at the time sort of a novelty, it's headline being "a way to do cryptography with smaller key sizes", as if ECC was mostly a way to fit crypto into smaller memory software. Schneier and Ferguson wrote _Practical Cryptography_ in 2003. It has virtually no mention whatsoever of ECC cryptography, despite ECC's already significantly increased importance by then. In 2013, I think it's fair to say that the balance of expert opinion on ECC vs. RSA is sharply against Schneier's take on ECC. RSA is on the way out, and ECC is what's going to replace it. Equally significantly, crypto constructions that use signing and key agreement but not public-key encryption/decryption operations are modern designs; designs where a long-lived RSA key is used to wrap and unwrap secrets are dated. ECC is useful for the modern constructions and less so for the dated ones. I don't think Schneier's writing has tracked these shifts well. I think his books are very light on, for instance, forward secrecy or deterministic signing. His research results never focused on public key encryption and never touched ECC (it's worth noting that much of his best known research was also done with John Kelsey, who is at NIST --- coincidentally, one of Schneier's best-known designs, with Kelsey, was the Yarrow CSPRNG). Also: Schneier has a close working relationship with Niels Ferguson, who was one of the researchers that spotted the weirdness in Dual_EC. So it's possible that Schneier's concerns over the "constants" in ECC all stem from that. (It's hard to say; he could also be referring to the random seed in the P-224 and P-256 curves). I don't think readers have any particular reason to believe that Bruce Schneier is an authority on ECC. Cryptography is not one topic. It's actually a little silly to suggest anyone like Schneier could be authoritative on all crypto concepts. Look at the research output of famous cryptographic researchers (Schneier has some research, but is not really a top-tier researcher) --- it tends to specialize!

intelliot 13y ago

reminds me of the State Science Institute

SimHacker 13y ago

Would you trust a computer security company who didn't hash the passwords of their users on their web site, and instead stored the plain text passwords encrypted in their database, with the keys to decrypt them on their server, because they claim that "Your data are encrypted on our server, if you request the password to be sent to you by email the system knows how to decrypt the information and it will send you the Email. This is for customer convenience as many customer do not wish their password to be reset each time they have a problem." Would you trust a computer security company that when you reset your password on their web site, sent you a new password that was literally the same as your email address that you signed in with? If this company sold closed source encryption software, would you trust that the software was competently written and did not have back doors, if the president of the company defended their actions of not hashing passwords, and of resetting passwords to their user's email addresses? What if the president of that company had been prosecuted for computer crimes in the past, and had spend time in jail for it, because after he was first caught, he went right back to phone freaking again and got caught again? Would you trust the president of the company, who is a convicted felon, who fraudulently made a lot of money by computer crime and got caught, but had most of the charges dropped and his sentence reduced, not to have made a deal with the government and promise to return their favor of giving him a more lenient sentence in exchange for certain favors in the future? Can anyone guess who I'm referring to?

SimHacker 13y ago
I'll give you some more hints: His company came out with a "secure" voice encryption product, and then a previously unknown anonymous hacker reviewed the product and its competitors, and wrote a suspiciously positive review of it, claiming it was the only one he couldn't break. His company then published a press release trumpeting the favorable review, right before a big mobile security conference. A suspicious security researcher baited the anonymous hacker to post on his blog, and it turned out he was using an ip addressed registered to the security company whose product he'd written a favorable review about. When confronted with proof, the founder of the security company denied astroturfing, denied knowing the hacker, and implausibly claimed the anonymous hacker must have been using his company's anonymous browsing service. The same security company founder who spent three years in jail for phone phreaking, because he was convicting of hacking and defrauding profit. The same security company who stores their user's passwords in unhashed unsalted plain text encrypted with a key on their server. The same security company who resets their user's passwords with their email address. The same security company whose founder claims that "many customer do not wish their password to be reset each time they have a problem" justifies not hashing passwords, and resetting passwords to "convenient" email addresses. The same security company whose founder refuses to change his "unconventional" security policies after being confronted with these facts, and instead makes ridiculous excuses for his incompetence, and continues to betray the trust of his customers even after he's been confronted with it. Can you figure out who it is now?