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

[openssl-dev] OpenSSL FIPS CAVP tests throws an error iob_func while linking

Hi All, I am trying to build CAVP test executable for WinCE. Most of the executable are built except 1-2. I am facing iob_func unresolved error. Every thing seems to be proper. Any idea or help is well appreciated. Regards Jaya -- openssl-dev mailing list To unsubscribe:

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

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.   Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217

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

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

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

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

> 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

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

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

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

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

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

-- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richs...@jabber.at Twitter: RichSalz From: Benjamin Kaduk via openssl-dev [mailto:openssl-dev@openssl.org] Sent: Tuesday, June 27, 2017 9:22 PM To: openssl-dev@openssl.org; Paul Dale Subject: Re:

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

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

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

Ben wrote: > 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

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

If the desired outcome is security you must generate instance unique keys and elegant software design alone is simply not enough to achieve that. And I didn't say solve below I said mitigate. You can't solve the problem of someone using already created keys in multiple VM's. But you can and

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

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

> 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

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 Consider most of the worlds compute is now done on VM's where images are

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