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]

Message-ID: <2140053.ysf7239sM3@tauon>
Date:	Thu, 12 Sep 2013 14:35:53 +0200
From:	Stephan Mueller <smueller@...onox.de>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	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

Am Donnerstag, 12. September 2013, 14:15:35 schrieb Geert Uytterhoeven:

Hi Geert,

>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.
>
>That is, if they have to be monotonic cycle counters.
>
>If not, I can mix the two (e.g. "a << 8 | (b & 0xff)") to get a 32-bit
>value. That result would be fine for /dev/random, I guess, but it's
>not really "get_cycles()".

Note, get_cycles should return an u64.

Not sure what a and b here is, but if a is the 24 bit value and b the 
faster 16 bit value, wouldn't there be a gap?

I.e. wouldn't it be better to use the full 16 bit counter as low value 
and OR the 24 bit on bits 48 to 17?

Yet, there is a break in that counter: the 16 low bits rotate several 
times (around 10 times) before bit 17 is changed once.


>
>Gr{oetje,eeting}s,
>
>                        Geert
>
>--
>Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
>geert@...ux-m68k.org
>
>In personal conversations with technical people, I call myself a
>hacker. But when I'm talking to journalists I just say "programmer" or
>something like that. -- Linus Torvalds


Ciao
Stephan
--
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/