Santiago Vila <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] [1]http://www.d.shuttle.de/isil/crypt/gnupg.html [2]see http://www.fourmilab.ch
