bugtraq - RE: /dev/random is probably not

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <MDEHLPKNGKAHNMBLJOLKMEAJFAAB.davids@webmaster.com>
Date: Thu, 7 Jul 2005 13:46:54 -0700
From: "David Schwartz" <davids@...master.com>
To: <tom@...ctric-sheep.org>, <bugtraq@...urityfocus.com>
Cc: "Robert Foxworth" <rfoxwor1@...pabay.rr.com>
Subject: RE: /dev/random is probably not



> > At the last place at which I worked, a few years ago, a "random
> > number" was generated, and used in a FIPS 140-1 compliant
> > encryption device, by capturing 128 ethernet frames in sequence
> > from the local in-house network, gathering the LSB from the
> > arrival time of each frame, and using those values to generate
> > an encryption key. This was part of the "activation sequence"
> > which had to be done, once, on each such device.
> >
> > Any studies out there on the randomness of such a number?
> > At first glance a non-deterministic network would seem to be
> > able to generate a useful number for the key.
>
> It doesn't look like a good source of entropy. At least it wouldn't
> withstand an active attack during this activation phase.
>
>
> > - Bob Foxworth, GSEC, CISSP

	What "active attack" allows an attacker to predict the jitter between the
network card's quartz oscillator and the frequency multiplier that generates
the CPU clock? The low order bit of the TSC at the time a packet is received
is believed to be almost purely a function of this jitter, for typical x86
CPUs at normal temperatures.

	DS