linux-kernel - Re: Replace /dev/random input mix polynomial with Brent's xorgen?

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: <20131215022147.GA24124@thunk.org>
Date:	Sat, 14 Dec 2013 21:21:47 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	George Spelvin <linux@...izon.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Replace /dev/random input mix polynomial with Brent's xorgen?

On Sat, Dec 14, 2013 at 04:55:59PM -0500, George Spelvin wrote:
> 
> What's critical for the input hash is that seed additions don't cancel
> each other.  That is, XORing in some new seed material doesn't hit
> the same bits as older seed material.  What's key is not exactly that
> additions affect lots of bits as that *different* additions affect
> *different* groups of bits.  In other words, differentials rather than
> single-bit avalanches,

Agreed, but that's we have the input_rotate.  Do you have analysis or
arguments why we Richard Brent's construction would do a better job?

BTW, one other design requirement I had when desining the mixing
function was if you fix in all zero's, the result was a reversible
mixing of the bits; in other words, "dd if=/dev/zero of=/dev/random"
is guaranteed to not lose any entropy caused by self-cancellation.

> The SHA-3 competition has given us lots of random permutations and
> random functions.  Keccak, Salsa20/ChaCha, Skein/Threefish and SipHash
> are all interesting looking.  AES/Rijndael is actually less so, unless
> you're planning on using hardware support, because of cache timing
> attacks on the lookup tables it needs for software implementation.

I'm not convinced we need to worry about cache timing attacks, since
they typically involve a chosen plaintext attack and a fixed key ---
and the attacker isn't going to know what we are going to be
encrypting, let alone be able to chose the plaintext.  Even if that
were not the case, see the paper, "Are AES x86 Cache Timing Attacks
Still Feasible?":

	http://cseweb.ucsd.edu/~hovav/dist/aes_cache.pdf

Regards,

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