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: <91981b3e05070520074d71b42f@mail.gmail.com>
Date: Tue, 5 Jul 2005 21:07:56 -0600
From: Chris Kuethe <chris.kuethe@...il.com>
To: Robert Foxworth <rfoxwor1@...pabay.rr.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: /dev/random is probably not


On 7/4/05, Robert Foxworth <rfoxwor1@...pabay.rr.com> wrote:
> 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.

OK, here's a quick set back-o-the-perl-script set of numbers.

I sampled a million packets off one of my fairly well used internet
links in 120.932020 seconds (according to tcpdump). I also sampled
209174 packets from my lan in 12507.724721 seconds (also according to
tcpdump).

Obviously I took the microsecond timestamp and extracted the low bit
for further processing. From these samples I grabbed a few 128bit
chunks from not-specially-selected offsets...

internet:
1000000 bits counted, 499888 x 0, 500112 x 1, longest string 30 bits
long was of 0
128 bits counted, 62 x 0, 66 x 1, longest string 10 bits long was of 1
128 bits counted, 57 x 0, 71 x 1, longest string 12 bits long was of 1
128 bits counted, 63 x 0, 65 x 1, longest string 10 bits long was of 1
128 bits counted, 68 x 0, 60 x 1, longest string 8 bits long was of 1
128 bits counted, 70 x 0, 58 x 1, longest string 8 bits long was of 0
128 bits counted, 76 x 0, 52 x 1, longest string 11 bits long was of 0
128 bits counted, 69 x 0, 59 x 1, longest string 8 bits long was of 0
128 bits counted, 61 x 0, 67 x 1, longest string 8 bits long was of 1
128 bits counted, 73 x 0, 55 x 1, longest string 11 bits long was of 0
128 bits counted, 74 x 0, 54 x 1, longest string 11 bits long was of 0

lan:
209174 bits counted, 104452 x 0, 104722 x 1, longest string 20 bits
long was of 0
128 bits counted, 56 x 0, 72 x 1, longest string 8 bits long was of 1
128 bits counted, 58 x 0, 70 x 1, longest string 7 bits long was of 1
128 bits counted, 54 x 0, 74 x 1, longest string 8 bits long was of 1
128 bits counted, 64 x 0, 64 x 1, longest string 6 bits long was of 0
128 bits counted, 66 x 0, 62 x 1, longest string 8 bits long was of 1
128 bits counted, 55 x 0, 73 x 1, longest string 11 bits long was of 1
128 bits counted, 73 x 0, 55 x 1, longest string 8 bits long was of 0
128 bits counted, 63 x 0, 65 x 1, longest string 6 bits long was of 1
128 bits counted, 64 x 0, 64 x 1, longest string 8 bits long was of 1
128 bits counted, 68 x 0, 60 x 1, longest string 6 bits long was of 1

CK

-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?