Date: Tue, 16 May 2006 15:37:35 -0500 (CDT)
From: Chase Venters <chase.venters@clientec.com>
To: Theodore Tso <tytso@mit.edu>
cc: Zvi Gutterman <zvi@safend.com>, "'Muli Ben-Yehuda'" <muli@il.ibm.com>,
       "'Kyle Moffett'" <mrmacman_g4@mac.com>,
       "'Alan Cox'" <alan@lxorguk.ukuu.org.uk>,
       "'Jonathan Day'" <imipak@yahoo.com>, linux-kernel@vger.kernel.org
Subject: Re: /dev/random on Linux
In-Reply-To: <20060516201749.GA10077@thunk.org>
Message-ID: <Pine.LNX.4.64.0605161534140.32181@turbotaz.ourhouse>
References: <20060516082859.GD18645@rhun.haifa.ibm.com>
 <00fc01c678f0$30c77520$2c02a8c0@Safend.com> <20060516201749.GA10077@thunk.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2067
Lines: 42

On Tue, 16 May 2006, Theodore Tso wrote:
B>
> 3) Investigate the possibility of adding quotas to /dev/random.  This
> is actually much more trickier that the paper suggests, since you want
> to allow the user to be able to extract enough entropy to create a
> 2048 bit (or at least a 1024-bit) RSA key.  The problem is that's a
> lot of entropy!  Maybe it would be OK to only allow a 1024-bit RSA key
> to be generated every 12 or 24 hours, but suppose someone is
> experimenting with GPG and screws up (say they forget their
> passphrase); do you tell them that sorry, you can't generating another
> key until tomorrow?  So now we have to have an interface so the root
> user can reset the user's entropy quota....  And even with a 24-hour
> limit, on a diskless system, you don't get a lot of entropy, so even a
> 1024-bit RSA key could seriously deplete your supply of entropy.

#3 is fine if it's out of the kernel. This isn't just policy - it's 
complicated policy, as you point out quite well.

> This last point is a good example of the concerns one faces when
> trying to design a working system in the real word, as opposed to the
> concerns of academicians, where the presence or lack of forward
> security in the event of a pool compromise is issue of massive urgency
> and oh-my-goodness-we-can-only-tell-the-maintainer-because-it's-such-a-
> critical-security-hole attitude.  Where as my attitude is, "yeah, we
> should fix it, but I doubt anyone has actually been harmed by this in
> real life", which puts it in a different category than a buffer
> overrun attack which is accessible from a publically available network
> service.
>

Slashdot headline about Linux's weak-ass rng should be up shortly, next to 
the news post discussing what Linus had for breakfast this morning.

> 						- Ted

Thanks,
Chase
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/