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?
"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
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!
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.
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.
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.
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.
