Random sources for 150+ hosts
Sam Roberts
sam@cogent.ca
Mon, 21 Aug 2000 12:43:31 -0400
--HCRqkzT7171pGTW9
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
You seem to be missing one possibility, implement a /dev/random for
IRIX and Tru64 Unix. Porting the OpenBSD random source to another
system should be trivial, I've done it to QNX4 and Neutrino. Basically,
you just have to implement read, and trap an interrupt, which is
pretty much as trivial a device driver as you can imagine.
Sam
Quoting Bjoern Fischer <bfischer@TechFak.Uni-Bielefeld.DE>, who wrote:
> Hello GnuPG users,
>=20
> we are planning to use GnuPG in a heterogenous environment:
> We need to support 150-200 hosts running Solaris, IRIX or
> Tru64 Unix.
>=20
> We are currently facing the difficulty to find good random
> sources on each host/platform. There are several methods to
> debate:
>=20
> 1. On Solaris use /dev/random (Andreas Meier's one, or that
> provided with the SUNWski); on IRIX and Tru64 Unix use
> egd. This requires that egd runs on every machine (except
> Suns). But even if egd runs under it's own user id, it
> still consumes resources massively (RAM, CPU,
> administration, etc.). I won't accept this unless everything
> else hurts even more.
>=20
> 2. On Solaris use /dev/random (Andreas Meier's one, or that
> provided with the SUNWski); for IRIX and Tru64 Unix provide
> a "centralized" egd-server via TCP socket. Our network
> environment is fully switched. Not that this ensures 100%
> security but it should be a hurdle against eavesdropping.
>=20
> 3. Implement a /dev/random in hardware, feed random to a
> randomness server and distribute it to all clients.
> This should provide high quality entropy, but this gain
> is damped (or lost at all?) if we send the random data
> unprotected (same as 2).
>=20
> At first glance 2 and 3 are inacceptable -- distributing random
> data over (switched) ethernet without further protection.
> But if bad guy is able to eavesdrop any traffic to and from
> a workstation there are many things far more interesting
> than random data for encryption purposes. E.g. you may listen
> to NFS traffic (homes and most apps NFS mounted), you may
> get the private PGP/GPG key and X11 authentication cookies,
> then you are able to contact the X11 server and get the pass
> phrase.
>=20
> What if we encrypt this random data? Even when using a weak
> encryption, there is no chance to perform a brute force attack,
> since there's no way to tell whether an attempt was successful
> or not.
> =20
> Suggestions are welcome.
>=20
> Bj=F6rn Fischer
>=20
> --=20
> -----BEGIN GEEK CODE BLOCK-----
> GCS d--(+) s++: a- C+++(-) UB++++OSI++++$ P+++(-) L---(++) !E W- N+ o>+
> K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+=
=20
> ------END GEEK CODE BLOCK------
>=20
> --=20
> Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
> with a subject of "unsubscribe" to gnupg-users-request@gnupg.org
>=20
--=20
Sam Roberts (sam@cogent.ca), Cogent Real-Time Systems (www.cogent.ca)
--HCRqkzT7171pGTW9
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (QNX)
Comment: For info see http://www.gnupg.org
iD8DBQE5oVwyZh6sjnrWpm0RArsyAKDhKTjuw1ARGVshUCLqv8alZb2xrgCeITBj
HzHgk7dXOaFSqiCJCl/Mv/o=
=Z3eW
-----END PGP SIGNATURE-----
--HCRqkzT7171pGTW9--
--
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of "unsubscribe" to gnupg-users-request@gnupg.org