All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan Mueller <stephan.mueller@atsec.com>
To: Ted Ts'o <tytso@mit.edu>, Steve Grubb <sgrubb@redhat.com>,
	Jarod Wilson <jarod@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>,
	linux-crypto@vger.kernel.org, Matt Mackall <mpm@sele
Subject: Re: [PATCH] random: add blocking facility to urandom
Date: Wed, 07 Sep 2011 23:27:12 +0200	[thread overview]
Message-ID: <4E67E1B0.2040309@atsec.com> (raw)
In-Reply-To: <20110907211858.GE20571@thunk.org>

On 07.09.2011 23:18:58, +0200, Ted Ts'o <tytso@mit.edu> wrote:

Hi Ted,

> On Wed, Sep 07, 2011 at 04:02:24PM -0400, Steve Grubb wrote:
>>
>> When a system is underattack, do you really want to be using a PRNG
>> for anything like seeding openssl?  Because a PRNG is what urandom
>> degrades into when its attacked.
> 
> This is not technically true.  urandom degrades into a CRNG
> (cryptographic random number generator).  In fact what most security
> experts recommend is to take a small amount of security, and then use
> that to seed a CRNG.

Correct.

However, a CRNG shall be reseeded once in a while - see standard crypto
libraries and their CRNGs (OpenSSL being a notable exception here). And
that is what this entire discussion is all about: to ensure that the
CRNG is reseeded with entropy, eventually.

> 
>> If enough bytes are read that an
>> attacker can guess the internal state of the RNG, do you really want
>> it seeding a openssh session?
> 
> In a cryptographic random number generator, there is a either a
> cryptographic hash or a encryption algorithm at the core.  So you
> would need a huge amounts of bytes, and then you would have to carry
> out an attack on the cryptographic core.

Correct.

And exactly that is the concern from organizations like BSI. Their
cryptographer's concern is that due to the volume of data that you can
extract from /dev/urandom, you may find cycles or patterns that increase
the probability to guess the next random value compared to brute force
attack. Note, it is all about probabilities.
> 
> If this is the basis for the patch, then we should definitely NACK it.
> It sounds like snake oil fear mongering.
> 
> 					- Ted
> 
> 
> 


-- 
Ciao
Stephan

WARNING: multiple messages have this Message-ID (diff)
From: Stephan Mueller <stephan.mueller@atsec.com>
To: "Ted Ts'o" <tytso@mit.edu>, Steve Grubb <sgrubb@redhat.com>,
	Jarod Wilson <jarod@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>,
	linux-crypto@vger.kernel.org, Matt Mackall <mpm@selenic.com>,
	Neil Horman <nhorman@redhat.com>,
	Herbert Xu <herbert.xu@redhat.com>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] random: add blocking facility to urandom
Date: Wed, 07 Sep 2011 23:27:12 +0200	[thread overview]
Message-ID: <4E67E1B0.2040309@atsec.com> (raw)
In-Reply-To: <20110907211858.GE20571@thunk.org>

On 07.09.2011 23:18:58, +0200, Ted Ts'o <tytso@mit.edu> wrote:

Hi Ted,

> On Wed, Sep 07, 2011 at 04:02:24PM -0400, Steve Grubb wrote:
>>
>> When a system is underattack, do you really want to be using a PRNG
>> for anything like seeding openssl?  Because a PRNG is what urandom
>> degrades into when its attacked.
> 
> This is not technically true.  urandom degrades into a CRNG
> (cryptographic random number generator).  In fact what most security
> experts recommend is to take a small amount of security, and then use
> that to seed a CRNG.

Correct.

However, a CRNG shall be reseeded once in a while - see standard crypto
libraries and their CRNGs (OpenSSL being a notable exception here). And
that is what this entire discussion is all about: to ensure that the
CRNG is reseeded with entropy, eventually.

> 
>> If enough bytes are read that an
>> attacker can guess the internal state of the RNG, do you really want
>> it seeding a openssh session?
> 
> In a cryptographic random number generator, there is a either a
> cryptographic hash or a encryption algorithm at the core.  So you
> would need a huge amounts of bytes, and then you would have to carry
> out an attack on the cryptographic core.

Correct.

And exactly that is the concern from organizations like BSI. Their
cryptographer's concern is that due to the volume of data that you can
extract from /dev/urandom, you may find cycles or patterns that increase
the probability to guess the next random value compared to brute force
attack. Note, it is all about probabilities.
> 
> If this is the basis for the patch, then we should definitely NACK it.
> It sounds like snake oil fear mongering.
> 
> 					- Ted
> 
> 
> 


-- 
Ciao
Stephan

  reply	other threads:[~2011-09-07 21:27 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-02 14:37 [PATCH] random: add blocking facility to urandom Jarod Wilson
2011-09-05  2:36 ` Sandy Harris
2011-09-06 14:09   ` Stephan Mueller
2011-09-07 17:38 ` Jarod Wilson
2011-09-07 18:12   ` Sasha Levin
2011-09-07 18:26     ` Jarod Wilson
2011-09-07 19:05       ` Sasha Levin
2011-09-07 19:30         ` Jarod Wilson
2011-09-07 20:00           ` Sasha Levin
2011-09-07 19:35         ` Neil Horman
2011-09-07 19:27       ` Ted Ts'o
2011-09-07 19:36         ` Jarod Wilson
2011-09-07 19:36           ` Jarod Wilson
2011-09-08  2:43           ` Sandy Harris
2011-09-07 19:49         ` David Miller
2011-09-07 20:02         ` Steve Grubb
2011-09-07 20:23           ` Sasha Levin
2011-09-07 20:30             ` Steve Grubb
2011-09-07 20:37               ` Sasha Levin
2011-09-07 20:56                 ` Steve Grubb
2011-09-07 21:10                   ` Sasha Levin
2011-09-07 21:28                     ` Steve Grubb
2011-09-07 21:38                       ` Sasha Levin
2011-09-07 21:35                     ` Jarod Wilson
2011-09-07 21:43                       ` Steve Grubb
2011-09-07 22:46                         ` Sven-Haegar Koch
2011-09-08  7:21                         ` Sasha Levin
2011-09-07 23:57                   ` Neil Horman
2011-09-08  6:41                     ` Tomas Mraz
2011-09-08 12:52                       ` Neil Horman
2011-09-08 13:11                         ` Steve Grubb
2011-09-08 13:49                           ` Neil Horman
2011-09-09  2:21                           ` Sandy Harris
2011-09-09 13:04                             ` Steve Grubb
2011-09-09 16:25                               ` Ted Ts'o
2011-09-09 21:27                               ` Thomas Gleixner
2011-09-12 13:56                                 ` Jarod Wilson
2011-09-13 10:58                                   ` Peter Zijlstra
2011-09-13 12:18                                     ` Jarod Wilson
2011-09-11  2:05                             ` Valdis.Kletnieks
2011-09-12 13:55                               ` Jarod Wilson
2011-09-12 16:58                                 ` Valdis.Kletnieks
2011-09-12 18:26                                   ` Jarod Wilson
2011-09-07 20:33           ` Neil Horman
2011-09-07 20:48             ` Steve Grubb
2011-09-07 21:18           ` Ted Ts'o
2011-09-07 21:27             ` Stephan Mueller [this message]
2011-09-07 21:27               ` Stephan Mueller
2011-09-07 21:38               ` Ted Ts'o
2011-09-08  8:44               ` Christoph Hellwig
2011-09-08 11:48                 ` Steve Grubb
2011-09-08 16:13                   ` David Miller
2011-09-09 19:08                     ` Eric Paris
2011-09-09 19:12                       ` Neil Horman
2011-09-08  8:42             ` Christoph Hellwig
2011-09-08  8:42               ` Christoph Hellwig
2011-09-07 21:20           ` Nikos Mavrogiannopoulos
2011-09-08  8:41           ` Christoph Hellwig
2011-09-12 14:02         ` Jarod Wilson
2011-09-12 14:02           ` Jarod Wilson
2011-09-12 14:58           ` Neil Horman
2011-09-12 17:06           ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E67E1B0.2040309@atsec.com \
    --to=stephan.mueller@atsec.com \
    --cc=jarod@redhat.com \
    --cc=levinsasha928@gmail.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=mpm@sele \
    --cc=sgrubb@redhat.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.