howto secure older keys after the recent attacks

[Christoph Anton Mitterer]

Hi folks.



On Thu, 2009-09-10 at 11:08 -0400, David Shaw wrote:
> The real headache here is (as always) the practical - what to do with  
> existing keys and such.  I suspect that removing SHA1 would  
> effectively mean a new key type for OpenPGP (again, not a disaster -  
> we're on our 4th key type today).
Wahhhh .... will loose all my signatures *G*
Ok seriously: ...


This is _really_ nice (especially as there are Debian packages for
it :-D)
> See also http://www.entropykey.co.uk/
Anyway,.. I'm really not an randomness-expert so perhaps some questions:

1) Is this already supported by gpg?


2) If so,.. where would gpg use it? Only for symmetric keys? Or also for
asymmetric?


3) One problem with such devices is,.. that one can never know (well at
least normal folks like me) how good they actually are.
If this company would be evil (subsidiary of NSA or so) they could just
sell bad devices that produce poor entropy thus rendering our (symmetric
and asymmetric) keys, signatures etc. "useless". Right?

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.

If there is such a "merging",.. how well does it work? I mean imagine
the device would be very evil (or just stupid) and produce only 0's or
1's or series of 0101's or something like this.
Would the "merging" produce entropy that's still as least as good as if
one would just have the kernel PRNG? Or would it yield in weaker
randomness.

(sorry for my non-expert terminology here ;) )


> > - When creating new keys (I'd like to "convince" some more friends to
> > take part :) )... should they create their keys with gpg1 or gpg2? Or
> > is the key generation equally secure?
> 
> Equally secure.  In fact, it's almost the same code.
I really wonder if you'll maintain both versions forever :-) ;)


Happy crypting,
Chris.
--
Grid Monkey
-------------- 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/82e6b26b/attachment-0001.bin>