On Fri, Dec 21, 2012 at 09:07:35PM +0100, Ondřej Bílka wrote:
> I was suggesting in another thread different approach.
>
> Use AES-based cryptographic random number generator as replacement of
> /dev/urandom. Reseeding would get done by changing both aes key and
> data.
>
> This would with hardw
On Sat, Dec 15, 2012 at 07:30:20PM -0500, Theodore Ts'o wrote:
>
> What I would do instead is use an AES-based cryptographic random
> number generator. That is, at boot time, grab enough randomness to
> for an AES key, and then use that key to create a cryptographic random
> number generator by e
On Sat, Dec 15, 2012 at 11:59:46PM +0100, Stephan Müller wrote:
> Am 15.12.2012 20:15, schrieb Ondřej Bílka:
> >Why not use nonblocking pool and seed nonblocking pool only with half of
> >collected entropy to get /dev/random in almost all practical scenarios
> >nonblocking?
>
> I would not recomme
Am 16.12.2012 01:30, schrieb Theodore Ts'o:
On Fri, Dec 14, 2012 at 06:36:41PM +0100, Stephan Mueller wrote:
That patch is about one week from a mainline merge, btw.
Initially I was also thinking about get_random_int. But stack protection
depends on non-predictable numbers to ensure it cannot b
On Fri, Dec 14, 2012 at 06:36:41PM +0100, Stephan Mueller wrote:
> >> That patch is about one week from a mainline merge, btw.
> > Initially I was also thinking about get_random_int. But stack protection
> > depends on non-predictable numbers to ensure it cannot be defeated. As
> > get_random_int d
Am 15.12.2012 20:15, schrieb Ondřej Bílka:
Why not use nonblocking pool and seed nonblocking pool only with half of
collected entropy to get /dev/random in almost all practical scenarios
nonblocking?
I would not recommend changing /dev/urandom. First, we would change the
characteristic of a ke
Why not use nonblocking pool and seed nonblocking pool only with half of
collected entropy to get /dev/random in almost all practical scenarios
nonblocking?
On Thu, Dec 13, 2012 at 08:44:36AM +0100, Stephan Mueller wrote:
> On 13.12.2012 01:43:21, +0100, Andrew Morton
> wrote:
>
> Hi Andrew,
> >
On 13.12.2012 08:44:36, +0100, Stephan Mueller wrote:
Hi Andrew,
> On 13.12.2012 01:43:21, +0100, Andrew Morton
> wrote:
>
> Hi Andrew,
>> On Tue, 11 Dec 2012 13:33:04 +0100
>> Stephan Mueller wrote:
>>
>>> Some time ago, I noticed the fact that for every newly
>>> executed process, the functio
On 13.12.2012 01:43:21, +0100, Andrew Morton
wrote:
Hi Andrew,
> On Tue, 11 Dec 2012 13:33:04 +0100
> Stephan Mueller wrote:
>
>> Some time ago, I noticed the fact that for every newly
>> executed process, the function create_elf_tables requests 16 bytes of
>> randomness from get_random_bytes. T
On Tue, 11 Dec 2012 13:33:04 +0100
Stephan Mueller wrote:
> Some time ago, I noticed the fact that for every newly
> executed process, the function create_elf_tables requests 16 bytes of
> randomness from get_random_bytes. This is easily visible when calling
>
> while [ 1 ]
> do
> cat /pro
On 11.12.2012 13:33:04, +0100, Stephan Mueller wrote:
Hi,
I just noticed a misuse of a variable in my initial patch
> + if (r->limit == 2 && r->entropy_count >= r->poolinfo->poolwords)
Instead of r->entropy_count, the code should use entropy_count.
Please see new patch attached.
Signed-of
Hi Ted, kernel hackers,
Some time ago, I noticed the fact that for every newly
executed process, the function create_elf_tables requests 16 bytes of
randomness from get_random_bytes. This is easily visible when calling
while [ 1 ]
do
cat /proc/sys/kernel/random/entropy_avail
sleep
12 matches
Mail list logo
