It looks like there are two different questions being addressed:
* How should OpenSSL architect the random number generators?
* How should these be seeded?
I agree with John that the larger threat comes from poor seeding, but both have
to be considered. A weak architecture will be just as bad
On 06/26/2017 12:41 PM, Salz, Rich wrote:
> We run in many environments, and I don't think it's reasonable to say
> that the RNG on someone's personal web server, perhaps on the
> Internet, is at the same level of criticality, say, as the same RNG
> running on something like a global CDN. I am no
On Mon, Jun 26, 2017 at 01:18:58PM -0700, John Denker via openssl-dev wrote:
> On 06/26/2017 12:41 PM, Salz, Rich wrote:
>
> > Suppose the chip supports RDRAND but the runtime doesn't have
> > getrandom or /dev/random?
>
> That's an easy one!
>
> Check the feature-test bit and then call RDRAND y
> > Suppose the chip supports RDRAND but the runtime doesn't have
> > getrandom or /dev/random?
>
> That's an easy one!
>
> Check the feature-test bit and then call RDRAND yourself.
> Code to do this exists, e.g.
Yeah, that's kinda what I meant we'd do.
--
openssl-dev mailing list
To unsubscr
On 06/26/2017 12:41 PM, Salz, Rich wrote:
> Suppose the chip supports RDRAND but the runtime doesn't have
> getrandom or /dev/random?
That's an easy one!
Check the feature-test bit and then call RDRAND yourself.
Code to do this exists, e.g.
https://en.wikipedia.org/wiki/RdRand#Sample_x86_asm_
On Mon, Jun 26, 2017 at 11:29:19AM -0700, John Denker via openssl-dev wrote:
> What's your threat model? I know that sounds like a cliché,
> but it's actually important.
>
> In particular, in my world the #1 threat against any PRNG
> is improper seeding.
> -- If you trust the ambient OS to pro
> As for reliability, I don't know what "mediocre" means. Usually security-
> critical code is correct or it's not. For a seed-source, either a lower
> bound on
> the amount of good "hard" randomness is available and reliable, or it's not.
We run in many environments, and I don't think it's rea
On 06/26/2017 11:51 AM, Salz, Rich wrote:
>> Combining many lousy sources and hoping that one of them will do
>> the job is not good engineering practice.
> But if there are a couple and they're both mediocre?
There are multiple dimensions to be considered, including reliability
and rate.
As fo
I was asked off-list why we're doing this. A reasonable question. :)
There are many complains about the OpenSSL RNG. For started:
https://github.com/openssl/openssl/issues/2168
https://github.com/openssl/openssl/issues/898
https://github.com/openssl/openssl/issues/2457
> Insofar as any hole that is not explicitly closed should be presumed open,
> then yes, there are many holes.
Any hole not known -- presumed open, or presumed closed? :) It's more about
> What's your threat model? I know that sounds like a cliché, but it's actually
> important.
We're trying
On 06/26/2017 09:17 AM, Salz, Rich wrote:
[snip]
> Does this make sense? Are there holes?
Even without the snipping, the proposal is very incomplete.
Insofar as any hole that is not explicitly closed should
be presumed open, then yes, there are many holes.
What's your threat model? I know tha
> Pseudorandomness of the output has been a design goal/requirement only
> in SHA-3 family. Any prior hash function’s exhibition of this property is
> coincidental.
>
> Therefore I suggest using SHA3 instead.
Is pseudorandomness a requirement? Or is it the "50% chance
> Do you think we need to use multiple sources of randomness? I think we
> should only use the one source, the one provided by the kernel.
Yes I think we will need to support it, such as systems that don't have kernel
support. Always whitening doesn't hurt, so I would like to see the simpler
lo
On Mon, Jun 26, 2017 at 04:17:41PM +, Salz, Rich via openssl-dev wrote:
>
> > > Is it worth reposting my thoughts with your suggested wording changes?
> >
> > OK. Off-list or on. This stuff is important.
>
> Reposting.
>
> My thoughts.
>
> Randomness should be whitened. Anything feed i
> Pseudorandomness of the output has been a design goal/requirement only
> in SHA-3 family. Any prior hash function’s exhibition of this property is
> coincidental.
>
> Therefore I suggest using SHA3 instead.
Is pseudorandomness a requirement? Or is it the "50% chance of a bitflip"?
--
openssl-
My thoughts.
Randomness should be whitened. Anything feed into an randomness pool,
should be mixed in and run through SHA256.
pool = SHA256(pool || new-randomness)
Pseudorandomness of the output has been a design goal/requirement only in SHA-3
family. An
On Mon, Jun 26, 2017 at 08:58:21AM -0700, John Denker via openssl-dev wrote:
> In the context of:
>
> >> If you mean for something to be hard for the attacker to guess,
> >> the word "adamance" can be used.
>
> On 06/26/2017 08:32 AM, Salz, Rich wrote:
>
> > All my attempts to look up a definiti
> > Is it worth reposting my thoughts with your suggested wording changes?
>
> OK. Off-list or on. This stuff is important.
Reposting.
My thoughts.
Randomness should be whitened. Anything feed into an randomness pool, should
be mixed in and run through SHA256.
pool = SHA25
> > Is it worth reposting my thoughts with your suggested wording changes?
>
> OK. Off-list or on. This stuff is important.
I will repost. And please also see https://github.com/openssl/openssl/pull/3773
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/op
In the context of:
>> If you mean for something to be hard for the attacker to guess,
>> the word "adamance" can be used.
On 06/26/2017 08:32 AM, Salz, Rich wrote:
> All my attempts to look up a definition of this word came up with a noun for
> for adamant.
The word "adamance", meaning hardnes
> Suggestion: Get rid of every mention of "entropy" from openssl code,
> documentation, design discussions, and everywhere else.
I like this and will do it. Except for our support of the EGD.
> Suggestion: In the common case where exact meaning is not important,
> "entropy" can be replaced by
On 06/26/2017 05:49 AM, Salz, Rich via openssl-dev wrote:
> We welcome your input.
Here is an observation plus some suggestions:
Using the word "entropy" in this context is unhelpful.
Normally, entropy means something very specific, in which
case using entropy to design and explain your RNG is
> Will the new architecture still allow engine-defined RNG methods? It's a
> critical requirement for our products.
Yes
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Dear Rich,
On Mon, Jun 26, 2017 at 3:49 PM, Salz, Rich via openssl-dev <
openssl-dev@openssl.org> wrote:
> We are starting to work on a new cryptographically strong pseudo random
> number generator for OpenSSL, known as CSPRNG or PRNG or RNG.
>
>
>
> Please take a look at GitHub pull request http
My thoughts.
Entropy should be whitened. Anything feed into an entropy pool, should be
mixed in and run through SHA256.
pool = SHA256(pool || new-entropy)
The current read and write file routines, and the current routine RAND_poll,
etc., will add to that global pool. The idea
101 - 125 of 125 matches
Mail list logo
