Re: [openssl-dev] Work on a new RNG for OpenSSL

>> Even opaque objects usually have some public interface. I think exposing >> RAND_add_ex() >> would be a good idea for 1.1..1, and it’s likely to serve as an acceptable >> “live forever” API. > > That’s my point. API decisions live forever. Point well taken. Nonetheless… > Suppose we

Re: [openssl-dev] Work on a new RNG for OpenSSL

➢ Even opaque objects usually have some public interface. I think exposing RAND_add_ex() would be a good idea for 1.1..1, and it’s likely to serve as an acceptable “live forever” API. That’s my point. API decisions live forever. Suppose we move around the DRBG’s so that they are

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Thu, Aug 24, 2017 at 05:47:55PM +, Salz, Rich via openssl-dev wrote: > > >This is why I want to add things like that by default in the > >additional data. > > On reseed or generate? Mostly on generate, but I see little point in not doing it on reseed. Kurt -- openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Thu, Aug 24, 2017 at 05:32:15PM +, Salz, Rich via openssl-dev wrote: > > >An idea that I had was to default to reseed on fork if we know we > >have a working syscall. ... to get entropy > > Or /dev device too? The point is that you can't be sure that /dev is still going to be

Re: [openssl-dev] Work on a new RNG for OpenSSL

>>I personally see no harm if these RNG objects are made available to >> applications that need/use them > > But decisions like this live forever. It is therefore VERY important to > spend time thinking about what > becomes part of the public API and what remains hidden so that we can

Re: [openssl-dev] Work on a new RNG for OpenSSL

>This is why I want to add things like that by default in the >additional data. On reseed or generate? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

>I personally see no harm if these RNG objects are made available to > applications that need/use them But decisions like this live forever. It is therefore VERY important to spend time thinking about what becomes part of the public API and what remains hidden so that we can change

Re: [openssl-dev] Work on a new RNG for OpenSSL

>An idea that I had was to default to reseed on fork if we know we >have a working syscall. Or /dev device too? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 8/24/17, 09:45, "openssl-dev on behalf of Steffen Nurpmeso" wrote: >> … But I think a new API, >> RAND_add_ex() that took a flag >> RAND_ADD_GLOBAL, RAND_ADD_LOCAL, RAND_ADD_PRIVATE, >> RAND_LOCAL_PRIVATE

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Thu, Aug 24, 2017 at 08:07:54AM +1000, Peter Waltenberg wrote: > The bad case I'm aware of is the fork() one as it's critical that the RNG > state diverge on fork(). Without that you can get some very nasty > behaviour in things like TLS servers. Some of which have a thread pool + > fork()

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Wed, Aug 23, 2017 at 05:12:56PM -0400, Paul Kehrer wrote: > On August 19, 2017 at 2:48:19 AM, Salz, Rich via openssl-dev ( > openssl-dev@openssl.org) wrote: > > > I think the safest thing is for us to not change the default. Programs that > know they are going to fork can do the right/safe

Re: [openssl-dev] Work on a new RNG for OpenSSL

"Blumenthal, Uri - 0553 - MITLL" wrote: |>So I guess you want an interface that can both add things to the |> "entropy" pool, and to the "additional data" pool? It shouldn't |>be that hard, I'll try to come up with some proposal soon. | |I’d say the interface

Re: [openssl-dev] Work on a new RNG for OpenSSL

Okay: https://github.com/openssl/openssl/pull/4239 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

com> To: "openssl-dev@openssl.org" <openssl-dev@openssl.org> Date: 24/08/2017 07:13 Subject: Re: [openssl-dev] Work on a new RNG for OpenSSL Sent by:"openssl-dev" <openssl-dev-boun...@openssl.org> On August 19, 2017 at 2:48:19 AM, Salz, Rich via openss

Re: [openssl-dev] Work on a new RNG for OpenSSL

On August 19, 2017 at 2:48:19 AM, Salz, Rich via openssl-dev ( openssl-dev@openssl.org) wrote: I think the safest thing is for us to not change the default. Programs that know they are going to fork can do the right/safe thing. It would be nicer if we could automatically always do the right

Re: [openssl-dev] Work on a new RNG for OpenSSL

>So I guess you want an interface that can both add things to the > "entropy" pool, and to the "additional data" pool? It shouldn't >be that hard, I'll try to come up with some proposal soon. I’d say the interface that Rich Salz proposed would be good enough: > … But I think a new

Re: [openssl-dev] Work on a new RNG for OpenSSL

Forgot to add that the adversary would have to compromise not only Intel but also AMD CPUs. Not sure about ARM - but if it implements RDRAND then it must be compromised too, otherwise the enemy victory wouldn be incomplete. ;-) And think of the chips powering mobile devices... Regards, Uri

Re: [openssl-dev] Work on a new RNG for OpenSSL

My offhand knee-jerk reaction would be that if you have a CPU compromised to that extent - the battle has been lost with no reason to continue. Going into more details, I checked that post, and disagree with the author (and I'm in a good company, as Linus seems to hold the same opinion).

Re: [openssl-dev] Work on a new RNG for OpenSSL

Uri wrote: >>It might also use things like RDRAND / RDSEED which we don't trust. > ... > From cryptography point of view, it cannot hurt, but may help a lot There is a scenario where it does hurt: https://www.lvh.io/posts/2013/10/thoughts-on-rdrand-in-linux.html This attack wouldn't be

Re: [openssl-dev] Work on a new RNG for OpenSSL

We should think carefully about what API’s we are exposing, and might want to wait for 1.1.2 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Mon, Aug 21, 2017 at 06:12:16PM +0200, Kurt Roeckx wrote: > So I guess you want an interface that can both add things to the > "entropy" pool, and to the "additional data" pool? It shouldn't > be that hard, I'll try to come up with some proposal soon. I was thinking about adding 2 callbacks.

Re: [openssl-dev] Work on a new RNG for OpenSSL

>I at least have a plan to add additional data, but probably not in >the current idea was probably not the way you would like to see it. :-) >My idea was to query at least various sources that we don't >attribute any entropy to, like getpid(), gettimeofday(), >

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Mon, Aug 21, 2017 at 03:56:29PM +, Blumenthal, Uri - 0553 - MITLL wrote: > >> P.S. I wonder if it's feasible to have a configuration parameter that > >> would allow me to tell the TLS code to invoke RAND_add_ex() before > >> generating session keys? > > > > Either you accept that

Re: [openssl-dev] Work on a new RNG for OpenSSL

>> P.S. I wonder if it's feasible to have a configuration parameter that would >> allow me to tell the TLS code to invoke RAND_add_ex() before generating >> session keys? > > Either you accept that NIST SP 90A is right, or you just bypass it > completely. We’re in the first camp.

Re: [openssl-dev] Work on a new RNG for OpenSSL

Offhand, I'd say it's a perfect solution. It allows me to mix in additional randomness when I want to the RNG that I think may need it. Exactly what I need. Thanks! P.S. I wonder if it's feasible to have a configuration parameter that would allow me to tell the TLS code to invoke

Re: [openssl-dev] Work on a new RNG for OpenSSL

"Salz, Rich" wrote: |Is this new RNG object available to user programs, or do they need |to reinvent the wheel even though they definitely link against the |OpenSSL library? | |You don’t have to re-invent the wheel, but you might have to modify \ |the source ☺

Re: [openssl-dev] Work on a new RNG for OpenSSL

Is this new RNG object available to user programs, or do they need to reinvent the wheel even though they definitely link against the OpenSSL library? You don’t have to re-invent the wheel, but you might have to modify the source ☺ Did you read the blog posting? What wasn’t

Re: [openssl-dev] Work on a new RNG for OpenSSL

"Salz, Rich via openssl-dev" wrote: |➢ But I’d like the development team to comment on (and ideally – accept) \ |my request to add RAND_add() method to the RNG that is used in generation \ |of private keys. | |Well, I’ve been thinking about this for a bit, since you

Re: [openssl-dev] Work on a new RNG for OpenSSL

➢ But I’d like the development team to comment on (and ideally – accept) my request to add RAND_add() method to the RNG that is used in generation of private keys. Well, I’ve been thinking about this for a bit, since you first raised it. I am still not sure of the need. And as the blog post

Re: [openssl-dev] Work on a new RNG for OpenSSL

The problem with /dev/urandom will go away sooner or later. All major platforms either have a CPRNG syscall for years or introduced one recently. BSD has getentropy(2) for a while, Windows has CryptGenRandom() and Linux has getrandom(2) since Kernel 3.2 and glibc 2.15.

Re: [openssl-dev] Work on a new RNG for OpenSSL

It seems to me this all depends on the order of things you do to create a daemon. You could make sure the RNG is inited, chroot, and then fork for instance. And I suspect there are actually programs that do it in that order. Yes. I think the safest thing is for us to not

Re: [openssl-dev] Work on a new RNG for OpenSSL

All the items discussed are important. But I’d like the development team to comment on (and ideally – accept) my request to add RAND_add() method to the RNG that is used in generation of private keys. Reason/justification: to be able to improve the available randomness by mixing in output from

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Fri, Aug 18, 2017 at 09:22:48AM +0200, Tomas Mraz wrote: > On Thu, 2017-08-17 at 22:11 +0200, Kurt Roeckx wrote: > > On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote: > > > On Thu, 2017-08-17 at 12:22 +, Salz, Rich via openssl-dev > > > wrote: > > > > I understand the concern.  

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Thu, 2017-08-17 at 22:11 +0200, Kurt Roeckx wrote: > On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote: > > On Thu, 2017-08-17 at 12:22 +, Salz, Rich via openssl-dev > > wrote: > > > I understand the concern.  The issue I am wrestling with is > > > strict > > > compatibility with

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote: > On Thu, 2017-08-17 at 12:22 +, Salz, Rich via openssl-dev wrote: > > I understand the concern.  The issue I am wrestling with is strict > > compatibility with the existing code.  Does anyone really *want* the > > RNG’s to not reseed

Re: [openssl-dev] Work on a new RNG for OpenSSL

I have only one issue with the current design: the apparent absence of RAND_add() interface for the "private" RNG. I request that it is added (no pun intended, really :). Regards, Uri Sent from my iPhone > On Aug 17, 2017, at 09:18, Salz, Rich via openssl-dev >

Re: [openssl-dev] Work on a new RNG for OpenSSL

\ > somewhere someone is. And then it’s not about just reseeding, but > what about when (if) we add other things, like whether or not the > secure arena gets zero’d in a child? It's difficult to think of what circumstances this might break existing code? What scenario did

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Thu, 2017-08-17 at 12:22 +, Salz, Rich via openssl-dev wrote: > I understand the concern.  The issue I am wrestling with is strict > compatibility with the existing code.  Does anyone really *want* the > RNG’s to not reseed on fork?  It’s hard to imagine, but maybe > somewhere someone is.  

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 17/08/17 13:22, Salz, Rich via openssl-dev wrote: > I understand the concern. The issue I am wrestling with is strict > compatibility with the existing code. Does anyone really *want* the > RNG’s to not reseed on fork? It’s hard to imagine, but maybe > somewhere someone is. And then it’s

Re: [openssl-dev] Work on a new RNG for OpenSSL

Great news and congratulations to everyone on landing this work. I see that the RNG is now capable of automatically reseeding itself on fork, which will be a huge win for applications that aren't rigorous about doing so themselves (read: most of them). However, it appears that OPENSSL_INIT_ATFORK

Re: [openssl-dev] Work on a new RNG for OpenSSL

And this is a very good answer. Perhaps this guidance deserves being documented somewhere besides this mailing list? Something along the lines of It is documented in the RAND_add manpage. ➢ I’m not sure I agree here. What effort are you talking about? In order to select an order in

Re: [openssl-dev] Work on a new RNG for OpenSSL

>>> Modify the source :) >> >>Very bad answer. > >And also a wrong one. Your application can always call RAND_add(). Sorry for mistake. And this is a very good answer. Perhaps this guidance deserves being documented somewhere besides this mailing list?

Re: [openssl-dev] Work on a new RNG for OpenSSL

>>> 3. What should I do if I want a given source to be used in addition to the >>> other sources, regardless of whether openssl thinks it got “enough bits” of >>> randomness or not? >> Modify the source :) >Very bad answer. And also a wrong one. Your application can always call

Re: [openssl-dev] Work on a new RNG for OpenSSL

>> 1. What’s the default if “with-rand-seed” was not provided? All of the >> listed supported types? None of them? Some of them…? > > As the first bullet says, it’s “os”. OK, thanks. > As for the second part of your question, it is deliberately not answered. > If you care, you’ll have

Re: [openssl-dev] Work on a new RNG for OpenSSL

> 1. What’s the default if “with-rand-seed” was not provided? All of the listed > supported types? None of them? Some of them…? As the first bullet says, it’s “os”. As for the second part of your question, it is deliberately not answered. If you care, you’ll have to read the source. (It’s

Re: [openssl-dev] Work on a new RNG for OpenSSL

Thanks everyone for the discussion (mainly in June) about this. There’s a blog post describing what we’ve done for the 1.1.1 release: https://www.openssl.org/blog/blog/2017/08/12/random/ Nice. But some important things could be made clearer. We added a new configuration parameter,

Re: [openssl-dev] Work on a new RNG for OpenSSL

Thanks everyone for the discussion (mainly in June) about this. There’s a blog post describing what we’ve done for the 1.1.1 release: https://www.openssl.org/blog/blog/2017/08/12/random/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

Executive summary: As has been said many times before, what we need (but do not have) is /one/ source of randomness that never blocks and never returns bits that are guessable by the adversary. In favorable cases, using getrandom(,,0) \*\ is appropriate for openssl. There are problems with

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 29 Jun 2017, at 06:03, Ben Laurie wrote: > > On 28 June 2017 at 03:41, Theodore Ts'o wrote: > On Wed, Jun 28, 2017 at 11:41:11AM +1000, Peter Waltenberg wrote: > > And FYI. On systems not backed with hardware RNG's /dev/random is > > extremely slow. 1-2

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 28 June 2017 at 03:41, Theodore Ts'o wrote: > On Wed, Jun 28, 2017 at 11:41:11AM +1000, Peter Waltenberg wrote: > > And FYI. On systems not backed with hardware RNG's /dev/random is > > extremely slow. 1-2 bytes/second is a DOS attack on it's own without any > > other effort

Re: [openssl-dev] Work on a new RNG for OpenSSL

m: Cory Benfield [mailto:c...@lukasa.co.uk] Sent: Wednesday, 28 June 2017 5:15 PM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Work on a new RNG for OpenSSL > On 28 Jun 2017, at 04:00, Paul Dale <paul.d...@oracle.com> wrote: > > > Peter Waltenberg wrote: >&g

Re: [openssl-dev] Work on a new RNG for OpenSSL

Re: [openssl-dev] Work on a new RNG for OpenSSL Sent by:"openssl-dev" <openssl-dev-boun...@openssl.org> > On 28 Jun 2017, at 04:00, Paul Dale <paul.d...@oracle.com> wrote: > > > Peter Waltenberg wrote: >> The next question you should be asking is: d

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 26 June 2017 at 18:10, Salz, Rich via openssl-dev < openssl-dev@openssl.org> wrote: > > 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

Re: [openssl-dev] Work on a new RNG for OpenSSL

Defence in depth seems prudent: independent sources with agglomeration and whitening. As Kurt noted, [on modern OSes,] it is really unclear what sources are available to us that are not already being used by the kernel. I would turn to hardware. Since OpenSSL already has assembly-level

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Wed, Jun 28, 2017 at 12:01:29PM -0500, Benjamin Kaduk via openssl-dev wrote: > > I'm not sure what you mean by "draining the kernel's entropy pools". > That is, if you are adhering to the belief that taking random bits out > of a generator removes entropy from it that must be replenished,

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 06/26/2017 11:28 PM, Paul Dale wrote: > Given the variety of RNGs available, would an EVP RNG interface make sense? > With a safe default in place (and no weak generators provided), the decision > can be left to the user. > A side benefit is that the unit tests could implement a simple fully

Re: [openssl-dev] Work on a new RNG for OpenSSL

Thanks for the quick reply. It sounds reasonable to make the default choice depending on the os environment. For me it is not a religious question what OpenSSL's default choice should be. I trust that you will find a sensible solution. And if OpenSSL supports both methods I can always make my

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 28/06/17 15:42, Matthias St. Pierre wrote: > Hello Matt, > > I am not quite sure what your current favourite solution for the upcoming > default OpenSSL random generator is. Are you favouring > > - a DRBG (following SP800-90Ar1) which is using the OS RNG as entropy source > for

Re: [openssl-dev] Work on a new RNG for OpenSSL

Hello Matt, I am not quite sure what your current favourite solution for the upcoming default OpenSSL random generator is. Are you favouring - a DRBG (following SP800-90Ar1) which is using the OS RNG as entropy source for (re-)seeding or - simply passing all generate requests over to the OS

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Wed, Jun 28, 2017 at 08:15:20AM +0100, Cory Benfield wrote: > When you say “the linked article”, do you mean the PCWorld one? > Because that article doesn’t provide any suggestion that > /dev/urandom has anything to do with it. It is at least as likely > that the SSH key is hard-coded into the

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 27/06/17 19:50, Benjamin Kaduk wrote: > On 06/27/2017 02:28 AM, Matt Caswell wrote: >> >> On 26/06/17 21:18, Kurt Roeckx wrote: >> >>> I think it should by default be provided by the OS, and I don't >>> think any OS is documenting how much randomness it can provide. >>> >> I also agree that,

Re: [openssl-dev] Work on a new RNG for OpenSSL

> On 28 Jun 2017, at 04:00, Paul Dale wrote: > > > Peter Waltenberg wrote: >> The next question you should be asking is: does our proposed design mitigate >> known issues ?. >> For example this: >>

Re: [openssl-dev] Work on a new RNG for OpenSSL

Peter Waltenberg wrote: > The next question you should be asking is: does our proposed design mitigate > known issues ?. > For example this: > http://www.pcworld.com/article/2886432/tens-of-thousands-of-home-routers-at-risk-with-duplicate-ssh-keys.html Using the OS RNG won't fix the lack of

Re: [openssl-dev] Work on a new RNG for OpenSSL

t: Re: [openssl-dev] Work on a new RNG for OpenSSL Sent by:"openssl-dev" <openssl-dev-boun...@openssl.org> On 06/27/2017 06:41 PM, Peter Waltenberg wrote: > Consider most of the worlds compute is now done on VM's where images are > cloned, duplicated and

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Wed, Jun 28, 2017 at 11:41:11AM +1000, Peter Waltenberg wrote: > And FYI. On systems not backed with hardware RNG's /dev/random is > extremely slow. 1-2 bytes/second is a DOS attack on it's own without any > other effort required. Please, stop suggesting the use /dev/random. The right

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Wed, Jun 28, 2017 at 01:50:49AM +, Salz, Rich wrote: > That's interesting info Ted, thanks. But we don't currently know > anything about which kernel or glibc version we're building for; > maybe that has to change. (We barely, and rarely, look at the > toolchain version.) And we need to

Re: [openssl-dev] Work on a new RNG for OpenSSL

the damage. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From: Benjamin Kaduk [mailto:bka...@akamai.com] Sent: Wednesday, 28 June 2017 11:22 AM To: openssl-dev@openssl.org; Paul Dale <paul.d...@oracle.com> Subj

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 06/27/2017 06:41 PM, Peter Waltenberg wrote: > Consider most of the worlds compute is now done on VM's where images are > cloned, duplicated and restarted as a matter of course. Not vastly > different from an embedded system where the clock powers up as 00:00 > 1-Jan, 1970 on each image. If

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Tue, Jun 27, 2017 at 04:12:48PM -0500, Benjamin Kaduk wrote: > > While you're here, would you mind confirming/denying the claim I read > that the reason the linux /dev/random tracks an entropy estimate and > blocks when it gets too low is to preserve backward security in the face > of attacks

Re: [openssl-dev] Work on a new RNG for OpenSSL

> Just to check my understanding, the claim is that adding more layers of > hashing and/or encryption will still be faster than a larger number of > syscalls? In terms of overall system performance? Yes. -- openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] Work on a new RNG for OpenSSL

ct: Re: [openssl-dev] Work on a new RNG for OpenSSL On 06/27/2017 07:24 PM, Paul Dale wrote: The hierarchy of RNGs will overcome some of the performance concerns. Only the root needs to call getrandom(). I do agree that having a DRBG at the root level is a good idea though. Just to check my underst

Re: [openssl-dev] Work on a new RNG for OpenSSL

That's interesting info Ted, thanks. But we don't currently know anything about which kernel or glibc version we're building for; maybe that has to change. (We barely, and rarely, look at the toolchain version.) And we need to be able to build a version which runs across a whole mess of

Re: [openssl-dev] Work on a new RNG for OpenSSL

roeckx.be>, John Denker <s...@av8n.com> Date: 28/06/2017 09:38 Subject: Re: [openssl-dev] Work on a new RNG for OpenSSL Sent by:"openssl-dev" <openssl-dev-boun...@openssl.org> On 06/27/2017 04:51 PM, Kurt Roeckx wrote: On Tue, Jun 27, 2017 at 11:56:04AM

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Tue, Jun 27, 2017 at 09:02:54PM +, Salz, Rich wrote: > > What is your concerns about syscall performance? What are your > > performance requirements? I can tell you that Chrome has been using > > /dev/urandom > > Well, Chrome ultimately works at human-scale. On the server side,

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 06/27/2017 07:24 PM, Paul Dale wrote: > > The hierarchy of RNGs will overcome some of the performance concerns. > Only the root needs to call getrandom(). > > I do agree that having a DRBG at the root level is a good idea though. > > > Just to check my understanding, the claim is that

Re: [openssl-dev] Work on a new RNG for OpenSSL

7217 Oracle Australia   From: Salz, Rich via openssl-dev [mailto:openssl-dev@openssl.org] Sent: Wednesday, 28 June 2017 4:56 AM To: Kaduk, Ben <bka...@akamai.com>; openssl-dev@openssl.org; Matt Caswell <m...@openssl.org> Subject: Re: [openssl-dev] Work on a new RNG for OpenSSL   For wi

Re: [openssl-dev] Work on a new RNG for OpenSSL

> In case it wasn't clear, I think we should use the OS provided source as a > seed. By default that should be the only source of randomness. I generally agree. But some applications might save their state and restore it during boot time, for example. -- openssl-dev mailing list To

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 06/27/2017 04:51 PM, Kurt Roeckx wrote: > On Tue, Jun 27, 2017 at 11:56:04AM -0700, John Denker via openssl-dev wrote: >> >> On 06/27/2017 11:50 AM, Benjamin Kaduk via openssl-dev wrote: >> >>> Do you mean having openssl just pass through to >>> getrandom()/read()-from-'/dev/random'/etc. or

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Tue, Jun 27, 2017 at 11:56:04AM -0700, John Denker via openssl-dev wrote: > On 06/27/2017 02:28 AM, Matt Caswell wrote: > >> > >> I also agree that, by default, using the OS provided source makes a lot > >> of sense. > > Reality is more complicated than that; see below. > > On 06/27/2017

Re: [openssl-dev] Work on a new RNG for OpenSSL

> RAND_set_rand_method(RAND_drbg_method()); > > FIPS_drbg_set_reseed_interval() and > FIPS_drbg_set_callbacks() Take a look at https://github.com/openssl/openssl/pull/3789 Thanks! -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

Hi Ted, On 06/27/2017 03:40 PM, Theodore Ts'o wrote: > > My recommendation for Linux is to use getrandom(2) the flags field set > to zero. This will cause it to use a CRNG that will be reseeded every > five minutes from environmental noise gathered primarily from > interrupt timing data. For

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Tue, Jun 27, 2017 at 06:55:47PM +, Salz, Rich via openssl-dev wrote: > Getrandom() is a syscall, and I have concerns about the syscall > performance. I would rather feed getrandom (or /dev/random if > that’s not available) into a FIPS DRBG generator. What is your concerns about syscall

Re: [openssl-dev] Work on a new RNG for OpenSSL

> > Getrandom() is a syscall, and I have concerns about the syscall > > performance. I would rather feed getrandom (or /dev/random if that’s > > not available) into a FIPS DRBG generator. > > What is your concerns about syscall performance? What are your > performance requirements? I can tell

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 06/27/2017 02:28 AM, Matt Caswell wrote: >> >> I also agree that, by default, using the OS provided source makes a lot >> of sense. Reality is more complicated than that; see below. On 06/27/2017 11:50 AM, Benjamin Kaduk via openssl-dev wrote: > Do you mean having openssl just pass through

Re: [openssl-dev] Work on a new RNG for OpenSSL

For windows RAND_bytes should just call CryptGenRandom (or its equiv). For modern Linux, probably call getrandom(2). For OpenBSD call arc4random(). Getrandom() is a syscall, and I have concerns about the syscall performance. I would rather feed getrandom (or /dev/random if that’s not

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 06/27/2017 02:28 AM, Matt Caswell wrote: > > On 26/06/17 21:18, Kurt Roeckx wrote: > >> I think it should by default be provided by the OS, and I don't >> think any OS is documenting how much randomness it can provide. >> > I also agree that, by default, using the OS provided source makes a lot

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Tue, Jun 27, 2017 at 02:42:52PM +0200, Matthias St. Pierre wrote: > > So I have two questions: > > - Do you intend to continue supporting RAND_set_rand_method() or will there > only be one 'perfect' random generator and no choice anymore? I think we should have a default one, but an option

Re: [openssl-dev] Work on a new RNG for OpenSSL

On Mon, Jun 26, 2017 at 09:39:47PM -0700, John Denker via openssl-dev wrote: > > I'm not mentioning any names, but some people are *unduly* > worried about recovery following compromise of the PRNG > internal state, so they constantly re-seed the PRNG, to > the point where it becomes a

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 27.06.2017 14:55, Salz, Rich via openssl-dev wrote: > That's three questions :) But yes, we should address that. I'm not sure if > new RAND API's are the way to go or perhaps a RAND_control API that gives us > a bit more flexibility. Ups, it used to be only two. That's always the problem

Re: [openssl-dev] Work on a new RNG for OpenSSL

> > Well maybe I can ignore section 10.3? > > > > That's a nice joke Rich, but the Dual_EC_DRBG chapter has been dropped in > SP800-90Ar1, which supersedes SP800-90A: I know. I was trying to gently point out that even John makes mistakes :) > - Do you intend to continue supporting

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 26.06.2017 20:51, Salz, Rich via openssl-dev wrote: > >> 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

Re: [openssl-dev] Work on a new RNG for OpenSSL

John, Thanks for pushing. It can be a thankless task, and I wanted to say thank you :) -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

> We welcome your input. On this topic, I would like to point out the construction we presented at SAC 2011 [1]. It implements a reseedable pseudo-random number generator in a rather simple way. One can supply seeds, extract pseudo-random numbers and apply a ratchet mechanism at any chosen time.

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 26/06/17 21:18, Kurt Roeckx wrote: >> “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

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 26/06/17 19:57, Salz, Rich via openssl-dev wrote: > 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 >

Re: [openssl-dev] Work on a new RNG for OpenSSL

In the context of >> What's your threat model? >> 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? On 06/26/2017 11:51 AM, Salz, Rich wrote: > Our TCB border is the process. That doesn't

Re: [openssl-dev] Work on a new RNG for OpenSSL

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

> > 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

  1   2   >