

Practical Kleptography [video] - todd8
https://www.usenix.org/conference/woot14/technical-sessions/presentation/practical-kleptography

======
kwantam
This talk mostly relates to the NSA's presumed poisoning of NIST SP 800-90A
Dual-EC PRNG. Previously it had been asserted that generating backdoored
parameters was extremely hard. Green et al have an accompanying paper at
USENIX Security that discusses practical exploitation of Dual-EC.

[http://dualec.org/DualECTLS.pdf](http://dualec.org/DualECTLS.pdf)

------
x0x0
Wow.

Matthew Green pointed out something really interesting that I, at least, was
unaware of. Apparently encryption libs do something breathtakingly stupid:
They use the same random streams for a nonce (ie an attacker may see it) then
immediately after use it for various other randomness needs within the
protocol. So if there is any weakness in the random generation, you're
exposing at least partial state of your random generator stream. Whereas if
one used different random streams for the nonce and then other needs, you
wouldn't be exposing as much state. Or at least that's my very non-expert
takeaway.

edit: rsa not only uses a broken prng by default, but they appear to have
actively aided the nsa.

~~~
alexjeffrey
your assumptions about cryptographically secure pseudorandom number generators
(CSPRNGs for short) are incorrect - one of the key requirements of secure
random number generation is the inability to predict future state given
previous state. See
[http://en.wikipedia.org/wiki/Cryptographically_secure_pseudo...](http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator),
particularly the part about the next-bit test.

The bit about RSA aiding the NSA is spot-on though, if dual EC DRBG is in fact
backdoored.

~~~
x0x0
You didn't understand.

Obviously it's a requirement to not be able to predict the future of a prng
given output from one. However (and the video discussed this!) that
requirement may be violated, either accidentally or on purpose.

Therefore, these protocols should be implemented in such a way that they are
more robust to defects in prngs. One such way is, obviously, not putting the
output of a prng in the clear, then using the next bits out of that prng.

