linux-kernel - Re: [PATCH] /dev/random: Insufficient of entropy on many architectures

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]

Date:	Thu, 12 Sep 2013 17:18:44 -0400
From:	Jörn Engel <joern@...fs.org>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Stephan Mueller <smueller@...onox.de>,
	Theodore Ts'o <tytso@....edu>,
	LKML <linux-kernel@...r.kernel.org>, dave.taht@...ferbloat.net
Subject: Re: [PATCH] /dev/random: Insufficient of entropy on many
 architectures

On Thu, 12 September 2013 14:15:35 +0200, Geert Uytterhoeven wrote:
> On Thu, Sep 12, 2013 at 2:08 PM, Stephan Mueller <smueller@...onox.de> wrote:
> >>BTW, I prefer a different name than "random_get_fast_cycles()", as it's
> >>better to have something that returns different and unpredictable
> >>numbers than an actual monotonic cycle counter.
> >
> > A monotonic counter is fully ok. Note, for /dev/random, the occurrence
> > of events delivers entropy. Thus, we have to be able to precisely
> > measure that occurrence. The timer itself does not need to deliver any
> > entropy as long as it is fast.
> 
> Well, in my specific case (m68k/Amiga) I can use:
>   - a 24-bit counter running at only ca. 15 or 31 kHz (actual
> frequency may vary),
>   - a 16-bit counter running at ca. 700 kHz.

Assuming the same cost, please use the 700kHz counter.  Or both.

Jiffies is a relatively poor choice, as it can be predicted with high
certainty.  Most of the time it will be identical to the last value
for jiffies, most of the remaining time it will be off by exactly one.
So on average you don't even get a single unpredictable bit from
jiffies.

A counter that is fast when compared to interrupt rate will give you
relatively many useful bits.  A slow counter - no matter how wide -
will have little useful randomness.  Ideal is a counter that cannot be
externally derived even with the most expensive measurement kit.  So
an unstable clock is actually a bonus.  Think high precision and low
realiability.

And if you have to drop bits from the counter, please drop the high
bits, as they are the easily predictable ones.

Jörn

--
I can say that I spend most of my time fixing bugs even if I have lots
of new features to implement in mind, but I give bugs more priority.
-- Andrea Arcangeli, 2000
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/