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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 Dec 2013 01:43:59 -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 Sun, Dec 15, 2013 at 11:22:47PM -0500, George Spelvin wrote:
> 
> > Um, no.  The *ciphertext* is the output.  The attacker can get all of
> > the ciphertext he or she wants by reading /dev/random (although we'd
> > probably do some folding as we currently do so the attacker won't even
> > get all of the ciphertext).  What the attacker has to be able to do is
> > given some of the ciphertext bits, be able to predict future
> > ciphertext bits given some construction which uses AES as the basis.
> 
> The attack I was thinking of was figuring out (without breaking root and
> using ptrace) what some *other* process on the same machine is reading
> from /dev/random.
> 
> In other words, reading someone else's output.

I understand that; and as I wrote in my last e-mail, I think that is a
substantially harder attack than the currently published cache timing
attacks, which are known plaintext attacks --- that is the attacker
doesn't know the key, but can choose the plaintext, and view the
resulting ciphertext.

In this case, the attacker doen't know the key *and* the plaintext; it
can view its own attempt to read from /dev/random, but from that, it
needs to be able to figure out the the key and the plaintext (i.e.,
the entropy pool) in order to be able to predict someone else's output
of /dev/random.

If you think this is easier than the currently published cache timing
attacks, please provide details why you think this is the case,
preferably in the form of a demonstration....

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