On Thu, 2009-09-10 at 20:38 -0400, Daniel Kahn Gillmor wrote: > Worse than this: the devices could produce measurably "good" entropy > that happens to be predictable to a malicious individual in control of a > special secret. > > For example, if such a key were to contain a copy of the secret, and > somehow retain the current time (e.g. a battery and a clock?), it could > produce a new output stream each second with: > > AES(secret + time()) > > (first cleartext block is just "secret + time", and next cleartext block > for that second is just the previous ciphertext block XOR'ed with > "secret + time" -- reset every second as time() changes) > > This would produce a predictable stream that (like all good ciphers) has > high-entropy output. > > Then, if this was used to provide random numbers to the kernel, which in > turn provided them to gpg, an attacker who knows the secret associated > with your entropy key, and the time you generated the key (that > information is published with your public key) could probably reproduce > the stream of "randomness" that was used for your key generation, and > therefore stumble upon your private key.
Ok,... now you've made me unsecure :-/ (on whether to use such a thingy - ok I've already ordered one ^^ - or not) Chris.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
