linux-kernel - Re: random(4) driver questions

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: <20110628144206.GJ2729@thunk.org>
Date:	Tue, 28 Jun 2011 10:42:06 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Sandy Harris <sandyinchina@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: random(4) driver questions

On Tue, Jun 28, 2011 at 02:02:58PM +0800, Sandy Harris wrote:
> However, for the secondary pools, a block cipher seems to
> me to be the obvious thing to use because there is plenty
> of analysis, in the Yarrow paper and follow-ups, of that
> technique. Also, I think it might be faster.

Well, there hasn't actually been any analysis of the use of a block
cipher.  The Yarrow paper and all follow-ons that I'm aware simply
assume that the block cipher is secure.  Most of the Yarrow analysis
has been on what I consider to be largely pointless, academic
considerations about "what if you're able to get the internal state".
(Whereas I'm of the opinion, if you can get access to the internal
state of the kernel, you probably can do a lot of other things that
are much bigger deal --- such as, dropping in a root exploit and then
start tapping your keyboard, network, etc.)

> An AES-128 context, 11 128-bit round keys, is roughly the
> same size as one of the current secondary pools, 32 32-bit
> chunks. What would maintainers think of a patch along
> those lines?

But if you're ditching the AES key scheduling step, it's no longer
AES, which means all of the analysis for AES not necessarily
applicable....  So if you're going for a cryptographic conservative
design, it's not at all clear to me that a bastardized AES is an
improvement.

Also, note that faster is *not* a feature for a random number
generator...

> Another question is whether and when we might replace
> SHA-1 with a more modern hash. Jeff Garzik has a patch
> to add Skein to the crypto API. That would be faster
> than SHA-1 and perhaps more easily analyzed since
> the compression function is a block cipher. Of course
> the SHA-3 Advanced Hash Standard process is not
> scheduled to finish for another year and there's a
> good argument that we should wait for that.

Waiting for SHA-3 (and then giving a bit more time for the
cryptographers to spend more time trying to attack it) seems like a
better approach to me....

						- Ted
--
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/