6 ms·

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 (w

by 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?

by devx 13y ago

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?