I continue to be suspicious about claims that userspace timing measurements are measuring anything other than OS behaviour. But that doesn't mean that they shouldn't exist. Personally, I believe you should try to collect as much entropy as you can, from as many places as you can. For VM's, it means we should definitely use paravirtualization to get randomness from the host OS. If you don't trust the host OS, then what on earth are you doing trying to generate a long-term public key pair on the VM in the first place? For that matter, why are you willing to expose a high value private keypair on the VM? For devices like Linux routers, what we desperately need is hardware assist; either a on-CPU hardware random number generator, or a hardware RNG from a TPM module, or having an individualized secret key generated at manufacturing time and burned onto the device. If you don't trust that the Intel hardware RNG honest, then by all means mix in additional timing information either at kernel device driver level, or from systems such as HAVEGE. What I'm against is relying only on solutions such as HAVEGE or replacing /dev/random with something scheme that only relies on CPU timing and ignores interrupt timing. Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
