Work on a new RNG for OpenSSL

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
81 messages Options
12345
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list

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 https://github.com/openssl/openssl/pull/3758 which is the start of a series.  In particular, please take a look at some detailed comments from one of our committers, at https://github.com/openssl/openssl/pull/3758#issuecomment-310938562, and the followon.

 

We welcome your input.

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: [hidden email] Twitter: RichSalz

 


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list

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 of cascading pools is neat.  We need at least one per thread, using our existing thread-local-storage API.  The current “lazy evaluation” will work fine, we don’t need a create-thread API.  We do need fork/exec protection which is the point of https://github.com/openssl/openssl/pull/3754

 

Each pool should have an atomic counter that is incremented when entropy is added.  Descendant pools can compare counters and mix in their parent when the counters don’t match.  Then when RAND_poll is called, or perhaps a new routine RAND_poll_system, it goes into the global pool and eventually all other pools will get it (whitened with their current state).  RAND_poll isn’t documented.

 

Per-thread pools don’t need a lock.  The global and other pools do.  Putting a pool in the SSL_CTX is probably reasonable.  I seriously doubt the SSL object needs it because the number of random bytes to generate keys is pretty small – we’ll expose things through AES misused first J  But adding it to the SSL object is simple so we might as well.

 

Then to generate random bytes use ChaCha.  See, for example, http://gitweb.dragonflybsd.org/dragonfly.git/blob/2aa3f894bd9b5b8f58a1526adb26663405b91679:/sys/kern/subr_csprng.c  My first thoughts on reading that code were, wow, is it really that easy?

 

We want to be able to save the current global state – write to a BIO – and restore it – read from a BIO.  This will let us reasonably work in low-entropy situations like system boot.

 

We want to provide a platform-neutral API that makes it’s best effort attempt to get entropy from the system and merge it into the global pool.  That should be a new API; I suggested RAND_poll_system above, but don’t really care

 

Does this make sense?  Are there holes?

 


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work on a new RNG for OpenSSL

Dmitry Belyavsky-3
In reply to this post by OpenSSL - Dev mailing list
Dear Rich,

On Mon, Jun 26, 2017 at 3:49 PM, Salz, Rich via openssl-dev <[hidden email]> 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 https://github.com/openssl/openssl/pull/3758 which is the start of a series.  In particular, please take a look at some detailed comments from one of our committers, at https://github.com/openssl/openssl/pull/3758#issuecomment-310938562, and the followon.

 

We welcome your input.


Will the new architecture still allow engine-defined RNG methods? It's a critical requirement for our products.
Thank you!


--
SY, Dmitry Belyavsky

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: discussion venue policy

OpenSSL - Dev mailing list
In reply to this post by OpenSSL - Dev mailing list
On 06/26/2017 05:49 AM, Salz, Rich wrote:

> Please take a look at GitHub pull request

Is the RNG topic going to be discussed on github, or on openssl-dev?
What about other topics?

Having some topics one place and some another seems like a Bad Idea™
Having a single topic split across multiple venues seems even worse.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list
In reply to this post by Dmitry Belyavsky-3
> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: discussion venue policy

OpenSSL - Dev mailing list
In reply to this post by OpenSSL - Dev mailing list
Discussion should be here on the mailing list.


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list
In reply to this post by OpenSSL - Dev mailing list
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 a bad
idea.  I can exhibit a distribution that has provably infinite
entropy, even though you can guess the exact output more than
25% of the time.

If perhaps you mean something else, calling it "entropy" is an
even worse idea.  It is likely that readers will misunderstand
what is written.

I am quite aware that the word appears in kernel source, but that
doesn't make it right.  It is used inconsistently, and AFAICT none
of the possible interpretations is really correct.

Note:  The real issue here it not the terminology.  Ideas are primary
and fundamental;  terminology is tertiary.  Terminology is only
important insofar as it helps us formulate and communicate the ideas.

There are at least five different ideas that need to be understood:
  1) The randomness of an ideal PRNG.
  2) The randomness of an ideal TRNG aka HRNG.
  3) The opposite, i.e. pure determinism.
  4) Squish, which is neither reliably predictable nor reliably unpredictable.
  5) Combinations of the above.


Suggestion:  Get rid of every mention of "entropy" from openssl
code, documentation, design discussions, and everywhere else.

Suggestion:  In the common case where exact meaning is not important,
"entropy" can be replaced by a noncommittal nontechnical word such
as "randomness".  Even so, it should be clearly documented that this
term is not meant to be quantitative.

Suggestion:  If you mean for something to be hard for the attacker
to guess, the word "adamance" can be used.  This can be quantified
in terms of the Rényi H_∞ functional, plus some additional attention
to detail (including specifying that it is a functional of the
attacker's macrostate, not anybody else's).

Suggestion:  In the remaining cases, which are not rare, it is
important to take a step back and figure out what is the actual
idea that is being (or should be) discussed.  This will not be
easy, but it must be done, line by line.  Otherwise the whole
enterprise is likely to be a waste of time.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list
> 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 a noncommittal nontechnical word such as
> "randomness".  Even so, it should be clearly documented that this term is not
> meant to be quantitative.

Okay.

> Suggestion:  If you mean for something to be hard for the attacker to guess,
> the word "adamance" can be used.

All my attempts to look up a definition of this word came up with a noun for for adamant.  Which is often appropriate, but maybe no here :)

> Suggestion:  In the remaining cases, which are not rare, it is important to take
> a step back and figure out what is the actual idea that is being (or should be)
> discussed.  This will not be easy, but it must be done, line by line.  Otherwise
> the whole enterprise is likely to be a waste of time.

We are trying hard not to waste anyone's time, a d we appreciate your input.  Is it worth reposting my thoughts with your suggested wording changes?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list
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 hardness (as in hard to guess),
was coined for this purpose.

The allusion to "adamance", meaning hardness (as in rheologically
hard), is not a coincidence.

Can anybody suggest a better term?

For more on this, and a host of RNG-related issues see:
  https://www.av8n.com/turbid/paper/rng-intro.htm

> Is it worth reposting my thoughts with your suggested wording changes?

OK.  Off-list or on.  This stuff is important.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list

> > 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/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list
In reply to this post by OpenSSL - Dev mailing list
 
> > 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 = SHA256(pool || new-randomness)

The current read and write file routines, and the current routine RAND_poll, etc., will add to that global pool.  The idea of cascading pools is neat.  We need at least one per thread, using our existing thread-local-storage API.  The current “lazy evaluation” will work fine, we don’t need a create-thread API.  We do need fork/exec protection which is the point of https://github.com/openssl/openssl/pull/3754

Each pool should have an atomic counter that is incremented when randomness is added.  Descendant pools can compare counters and mix in their parent when the counters don’t match.  Then when RAND_poll is called, or perhaps a new routine RAND_poll_system, it goes into the global pool and eventually all other pools will get it (whitened with their current state).  RAND_poll isn’t documented.

Per-thread pools don’t need a lock.  The global and other pools do.  Putting a pool in the SSL_CTX is probably reasonable.  I seriously doubt the SSL object needs it because the number of random bytes to generate keys is pretty small – we’ll expose things through AES misused first ?  But adding it to the SSL object is simple so we might as well.

Then to generate random bytes use ChaCha.  See, for example, http://gitweb.dragonflybsd.org/dragonfly.git/blob/2aa3f894bd9b5b8f58a1526adb26663405b91679:/sys/kern/subr_csprng.c  My first thoughts on reading that code were, wow, is it really that easy?

We want to be able to save the current global state – write to a BIO – and restore it – read from a BIO.  This will let us reasonably work in low-randomness situations like system boot.

We want to provide a platform-neutral API that makes its best effort attempt to get randomness from the system and merge it into the global pool.  That should be a new API; I suggested RAND_poll_system above, but don’t really care.

Does this make sense?  Are there holes?

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: discussion venue policy

Kurt Roeckx
In reply to this post by OpenSSL - Dev mailing list
On Mon, Jun 26, 2017 at 07:30:52AM -0700, John Denker via openssl-dev wrote:
> On 06/26/2017 05:49 AM, Salz, Rich wrote:
>
> > Please take a look at GitHub pull request
>
> Is the RNG topic going to be discussed on github, or on openssl-dev?
> What about other topics?
>
> Having some topics one place and some another seems like a Bad Idea™
> Having a single topic split across multiple venues seems even worse.

I think general discussion about a topic should be here,
discussion about a specific patch should be on github.


Kurt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work on a new RNG for OpenSSL

Kurt Roeckx
In reply to this post by OpenSSL - Dev mailing list
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 definition of this word came up with a noun for for adamant.
>
> The word "adamance", meaning hardness (as in hard to guess),
> was coined for this purpose.
>
> The allusion to "adamance", meaning hardness (as in rheologically
> hard), is not a coincidence.
>
> Can anybody suggest a better term?

unpredictable?


Kurt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work on a new RNG for OpenSSL

Blumenthal, Uri - 0553 - MITLL
In reply to this post by OpenSSL - Dev mailing list
      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. Any prior hash function’s exhibition of this property is coincidental.

Therefore I suggest using SHA3 instead.
 

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list
> 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-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work on a new RNG for OpenSSL

Kurt Roeckx
In reply to this post by OpenSSL - Dev mailing list
On Mon, Jun 26, 2017 at 04:17:41PM +0000, 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 into an randomness pool, should be mixed in and run through SHA256.
>                 pool = SHA256(pool || new-randomness)

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. All sources of randomness already go in it, there is no
need for us to try add any other source that it's already using.

So there should be no need to do any whitening.

> Each pool should have an atomic counter that is incremented when randomness is added.  Descendant pools can compare counters and mix in their parent when the counters don’t match.  Then when RAND_poll is called, or perhaps a new routine RAND_poll_system, it goes into the global pool and eventually all other pools will get it (whitened with their current state).  RAND_poll isn’t documented.

The only thing the pool should care about is that it's been
initialized or not, and if it needs to add more data to it or not.

> Then to generate random bytes use ChaCha.  See, for example, http://gitweb.dragonflybsd.org/dragonfly.git/blob/2aa3f894bd9b5b8f58a1526adb26663405b91679:/sys/kern/subr_csprng.c  My first thoughts on reading that code were, wow, is it really that easy?

You might also want to take a look at something like:
https://github.com/smuellerDD/chacha20_drng/blob/master/chacha20_drng.c

> We want to be able to save the current global state – write to a BIO – and restore it – read from a BIO.  This will let us reasonably work in low-randomness situations like system boot.

Ideally we should refuse to operate in a situation where the kernel
didn't initialize it's RNG yet. I only know about Linux being broken
in this regard, and getrandom() / getentropy() really should be
available on them by now. I don't think we should add a workaround
by reading 1 byte from /dev/random if getrandom() isn't available.


Kurt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list
> 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 logic of always doing it.  And also for the case where existing applications mix in their own.

> > Each pool should have an atomic counter that is incremented when
> randomness is added.  Descendant pools can compare counters and mix in
> their parent when the counters don’t match.  Then when RAND_poll is
> called, or perhaps a new routine RAND_poll_system, it goes into the global
> pool and eventually all other pools will get it (whitened with their current
> state).  RAND_poll isn’t documented.
>
> The only thing the pool should care about is that it's been initialized or not,
> and if it needs to add more data to it or not.

In order to maintain conceptual compatibility with the current API, I think that when someone does RAND_poll or RAND_add, they are expecting it to be be used.  I think having a "added_count" field in every pool, and doing a check is simple way to ensure that changes to the global pool propagate down.

> You might also want to take a look at something like:
> https://github.com/smuellerDD/chacha20_drng/blob/master/chacha20_drn
> g.c

Is there any reason why this is better than the other mechanisms?

> > We want to be able to save the current global state – write to a BIO – and
> restore it – read from a BIO.  This will let us reasonably work in low-
> randomness situations like system boot.
>
> Ideally we should refuse to operate in a situation where the kernel didn't
> initialize it's RNG yet. I only know about Linux being broken in this regard, and
> getrandom() / getentropy() really should be available on them by now. I
> don't think we should add a workaround by reading 1 byte from
> /dev/random if getrandom() isn't available.

We're not yet in the ideal world, and all the world's not a modern Linux kernel :)  I believe we need to give applications an "escape hatch" to let them read/write the global state.  And also think of embedded devices where perhaps the state is in NVRAM.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work on a new RNG for OpenSSL

Blumenthal, Uri - 0553 - MITLL
In reply to this post by OpenSSL - Dev mailing list
    > 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"?

For [P]RNG?! In one word: yes.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list
In reply to this post by OpenSSL - Dev mailing list
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 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 provide a seed, why not
  trust it for everything, and not bother to implement an
  openssl-specfic RNG at all?
 -- Conversely, if you don't trust the OS, what makes you
  think you can solve a problem the OS failed to solve,
  especially without knowing why it failed?

And (!) what do you propose to do when a suitable seed is not
available at the moment but might be available later?

Are you designing to resist an output-text-only attack?  Or do
you also want "some" ability to recover from a compromise of
the PRNG internal state?

Is there state in a persistent file, or only in memory?


> Randomness should be whitened.  Anything feed into an randomness
> pool, should be mixed in and run through SHA256. pool = SHA256(pool
> || new-randomness)

Just having a pool and a hash function is not enough.  Not
even close.

Constructive suggestion:  If you want to see what a RNG looks
like when designed by cryptographers, take a look at:
  Elaine Barker and John Kelsey,
  “Recommendation for Random Number Generation Using Deterministic Random Bit Generators”
  http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf

That design may look complicated, but if you think you can
leave out some of the blocks in their diagram, proceed with
caution.  Every one of those blocks is there for a reason.

> Randomness should be whitened.

Whitening at the input is neither difficult nor necessary nor sufficient.
The hard part is obtaining a reliable lower bound on the amount of
useful randomness in the bit-blob when it appears at the input.  Where
did the bits come from?  Where did the bound come from?  Do you trust
the generic openssl user, who knows nothing about cryptology, to provide
either one?

> The idea of cascading pools is neat.

Cascading is absolutely necessary, and must be done "just so", to
prevent track-and-hold attacks.  One of the weaknesses in the
Enigma, exploited to the hilt by Bletchley Park, was that each
change in the internal state was too small.  A large state space
is not sufficient if the state /changes/ are small.

On 06/26/2017 10:12 AM, Kurt Roeckx wrote:

>> Do you think we need to use multiple sources of randomness?

Quality is more important than quantity.

N reliable sources is marginally better than N-1 reliable sources.
One reliable source is immeasurably better than any number of
unreliable sources.

Combining many lousy sources and hoping that one of them will do
the job is not good engineering practice.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Work on a new RNG for OpenSSL

OpenSSL - Dev mailing list
> 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 to do a better job than the current stuff.  We want to provide a good cross-platform API that uses the operating system when it's worth doing so.

There are lots of vague words in that.  Deliberately.
 
>  --  If you trust the ambient OS to provide a seed, why not
>   trust it for everything, and not bother to implement an
>   openssl-specfic RNG at all?

Because the ambient OS isn't one, but is one of many possibilities.  A good kernel getrandom might exist, a good /dev/random might exist, either might exists but be bad, and one might exist and be good.  We want to assume the minimum set of O/S facilities, and try to develop code that has the minimum set of ifdef's or run-time code paths.  Again, there are vague words there.  But code that's perfect but impenetrable does not help our user base.

>  -- Conversely, if you don't trust the OS, what makes you
>   think you can solve a problem the OS failed to solve,
>   especially without knowing why it failed?
>
> And (!) what do you propose to do when a suitable seed is not available at
> the moment but might be available later?

Leave it up to the application to decide.   It would be nice to say "fix the platform" but we run on places where that is not possible.  Right now I believe (and this entire note is my opinion) that the best we can realistically do is make it possible for portable safe applications to do the right thing.
 
> Are you designing to resist an output-text-only attack?  Or do you also want
> "some" ability to recover from a compromise of the PRNG internal state?

Our TCB border is the process.

> Is there state in a persistent file, or only in memory?

Only memory.

> Just having a pool and a hash function is not enough.  Not even close.

I wasn't suggesting just those.  I was saying that's the pool, and then something like chacha.

> Constructive suggestion:  If you want to see what a RNG looks like when
> designed by cryptographers, take a look at:
>   Elaine Barker and John Kelsey,
>   “Recommendation for Random Number Generation Using Deterministic
> Random Bit Generators”
>   http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf
>
> That design may look complicated, but if you think you can leave out some of
> the blocks in their diagram, proceed with caution.  Every one of those blocks
> is there for a reason.

Well maybe I can ignore section 10.3?
 
> Do you trust the generic
> openssl user, who knows nothing about cryptology, to provide either one?

No, which is why we'll have a mixin-from-system API that will hopefully do the right thing.  Ideally on all places where openssl runs.

> 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?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
12345
Loading...