howto secure older keys after the recent attacks

Christoph Anton Mitterer christoph.anton.mitterer at
Fri Sep 11 11:20:32 CEST 2009

On Thu, 2009-09-10 at 22:35 -0400, David Shaw wrote:
> Yes.  It's not that gpg has a driver for it though.  The developers of  
> the entropy key were clever and instead of making programs write new  
> code to use the key, they made a program that reads the key and feeds  
> the Linux entropy pool.  Thus, anything that uses /dev/random (like  
> gpg) benefits without code changes.
Nice nice :)

Apart from that,.. I've just read that they support even having more of
those devices added,.. for an even higher entropy bandwidth :D

> Not completely useless given the Linux random design, but certainly an  
> evil source of entropy would be a serious problem.  Do you have any  
> reason to believe this device is evil?
_Not at all_ ... But the problem is,.. how could I know? Nor would I
have the technical knowledge to verify their implementation,.. nor the
elecetron microscope that I'd probably need for the verification.

> There are many random number  
> generators on the market.  Knowing which ones are evil would be handy ;)
Well,.. as soon as I got a list,.. I promise that I'll tell you ...
EXCEPT... I'm already detained in Guantanamo, Diego Garcia,.. or
something like this ... for knowing that list ;)
But in this case we might probably meet anyway,.. as _all_ people I've
ever had contact to,.. will be detained, too ;)

> > So my question is basically,..
> > If gpg would use this,... does it only improve the already existing
> > entropy and randomness of the kernel PRNG? I mean that gpg somehow
> > "merges" the different sources?
> > Or is it more or less a,.. either use the kernel PRNG or the hardware
> > RNG.
> The kernel merges several sources of entropy into the /dev/random  
> pool.  The entropy key would just be another source (though a very  
> prolific source) of entropy.
So this basically means:
Use such devices (as much as possible), they practically can only
improve security, but not weaken?

-------------- 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/9d39eaf5/attachment-0001.bin>

More information about the Gnupg-users mailing list