Mailing List Archive

"Michael.Fischer.von.Mollard" <fischer@math.uni-goettingen.de> writes:

> I just compiled (with minor problems) GPG v0.9.2 on an Alpha (Digital
> unix) and I'm just a little bit curious whether it is a good idea to use
> it with my old private key (generate at home). Any answers?

Don't do this as it may leak out your private key. It is okay to use
your key on the alpha for decryption and verification

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> "MFvM" == Michael Fischer von Mollard <fischer@math.uni-goettingen.de> writes:
>
> MFvM> Just a short question: When is the RNG actually needed? Only for key
> MFvM> generation?
>
> No, the PRNG is required every time a session key is generated, as the PRNG
> is the source of the session key.

Not a Pseudo RNG is needed but a RNG. The difference is that a PRNG
outputs a well defined sequence of random bytes once it has been
seeded.

DSA signatures and ElGamal encryption rely on a secret parameter k
which is only needed during the process of signing/encrypting and
this k never leaves the function. This k has to be generated by a
*good* RNG other wise your secret key will leak out.


Werner

On 01/29/1999 11:53 +0100, Werner Koch wrote:
>>
>> Not a Pseudo RNG is needed but a RNG. The difference is that a PRNG
>> outputs a well defined sequence of random bytes once it has been
>> seeded.

I have written a not-quite-so-pseudo-RNG that I use for some small applications
that I've developed. It's based on the Xrand48 functions but also includes
factors from the current time-of-day (time() et. al.) and Solaris' high-resolution
timers (gethrtime(), gethrvtime()). I know that the high res timers are
not supported on all platforms, but considering the interface they provide
(there is no well-defined zero point - all you are guaranteed is that the
values are monotonically increasing and that they are reasonably accurate
to some hardware-defined resolution), they seemed like a fair candidate for
helping avoid absolute predictability. I haven't done any formal analysis
of the algorithm, but it has been more than suitable for my needs. I'm
curious whether a similar approach has been considered for GPG (or other
uses) - I know there would be some portability issues, but it might
be simpler than a separate daemon and quicker than compressing/encrypting
a bunch of files... Any thoughts?


tw



--
+--------------------------------------+------------------------------------+
| Tim Walberg | Phone: (847) 632-3407 |
| Motorola CE/ITS | Pager: (800) SKY-TEL2 PIN:1384689 |
| 1475 W Shure Dr. IL75-2H14 | FAX: (847) 632-5769 |
| Arlington Heights, IL 60004 | |
+--------------------------------------+------------------------------------+
| http://www.cig.mot.com/~walberg | E-mail: walberg@cig.mot.com, |
| http://www.skytel.com/Paging (pager) | 1384689@skytel.com (pager) |
+--------------------------------------+------------------------------------+

Tim Walberg <walberg@cig.mot.com> writes:

> factors from the current time-of-day (time() et. al.) and Solaris' high-resolution
> timers (gethrtime(), gethrvtime()). I know that the high res timers are
> not supported on all platforms, but considering the interface they provide

GnuPG usees this for the fast_poll function but I think that we need
better sources.