howto secure older keys after the recent attacks

Christoph Anton Mitterer christoph.anton.mitterer at
Fri Sep 11 11:25:53 CEST 2009

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)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3387 bytes
Desc: not available
URL: </pipermail/attachments/20090911/348b7092/attachment.bin>

More information about the Gnupg-users mailing list