Re: Native PGP-signing now possible.
Santiago Vila <sanvila@unex.es> writes:
> Since we have not switched to GPG yet, I have compiled PGP for the Hurd.
> The packages are currently in the Incoming dir in nonus.debian.org.
>
> I just wanted to warn everybody that while compiling this, the following
> message was issued:
>
> Warning: getrusage is not implemented and it will always fail.
>
> So this may be suitable for signing using an already existing keyring,
> but it is possible that it is not as suitable for generating keys (pgp
> uses the getrusage function to obtain some random bits).
GPG has (according to the webpage[1]) been tested on GNU 0.2 and found to
work with the sole exception of a lack of cryptographically sound
random numbers. As is the case for PGP, cryptographically sound
random numbers are necessary on every usage, since most encryption is
done with a symmetric cipher using a random key. Under GNU/Linux, the
Linux /dev/random is used to produce cryptographically sound random
numbers; on other OS PGP uses miscellaneous methods. GPG supports
only /dev/random.
To clarify: PGP will not produce securely encrypted documents in
Debian GNU/Hurd if it cannot obtain true random bits. It needs random
bits for every encryption or signature operation, as well as key
generation.
The obvious solution is to port the Linux /dev/random to the Hurd.
However, the Linux /dev/random relies on pieces throughout the kernel
calling the following functions:
[from /usr/src/kernel-source-2.2.1/drivers/char/random.c]
* void add_keyboard_randomness(unsigned char scancode);
* void add_mouse_randomness(__u32 mouse_data);
* void add_interrupt_randomness(int irq);
* void add_blkdev_randomness(int irq);
This suggests that it may be awkward to implement a /dev/random in a
more modular kernel such as the Hurd. The Linux souce code can be
used to do the hashing and bit-munging, but it will probably be
necessary to design some sort of "randomness server" which other
servers feed bits of randomness. It will be important to keep input
acces to this device limited; otherwise an attacker might be able to
control or predict the random bits.
It will then be necessary to modify the appropriate servers, or
possibly gnumach itself, to feed random bits to the randomness server.
On the plus side, such an architecture could easily incorporate random
bits from other sources, such as radio tuner cards, Geiger
counters[2], and other miscellaneous hackery.
Andrew Archibald
aarchiba@csclub.uwaterloo.ca
[1]http://www.d.shuttle.de/isil/crypt/gnupg.html
[2]see http://www.fourmilab.ch
Reply to: