On Sep 25, 2013 8:06 AM, "John Kelsey" <crypto....@gmail.com> wrote: > On Sep 22, 2013, at 8:09 PM, Phillip Hallam-Baker <hal...@gmail.com> wrote: > > Either way, the question is how to stop this side channel attack. > > One simple way would be to encrypt the nonces from the RNG under a > > secret key generated in some other fashion. > > > > nonce = E (R, k) > > This would work if you had a secure key I couldn't guess for k. If > the entropy is really low, though, I would still see duplicate outputs > from time to time. If the RNG has short cycles, this would also show > up.
Note that Kerberos "confounds": it encrypts it's nonces for AES in CTS mode (similar to CBC). Confounding makes it harder to exploit a backdoored RNG if the exploit is made easier by the ability to see RNG outputs as nonces. I'm not sure how much harder though: presumably in the worst case the attacker has the victim's device's seed somehow (e.g., from a MAC address, purchase records, ...), and can search its output via boot and iteration counter searches (the details depend on the PRNG construction, obviously). Seeing an RNG output in the clear probably helps, but the attacker could design the PRNG such that they don't need to. Now, there's a proposal to drop confounding for new cipher suites in Kerberos. Among other things doing so would improve performance. It would also make analysis of the new cipher suites easier, as they'd match what other standard protocols do. Of course, I'd rather implementations have a strong enough RNG and SRNG -- I'd rather not have to care if some RNG outputs are trivially available to attackers. But if confounding is a net security improvement for PRNG-only use cases (is it? it might depend on the PRNG construction and boot-time seed handling), maybe we should keep it. Thoughts? Nico -- _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography