Re: [openssl-dev] Plea for a new public OpenSSL RNG API

I like this PR. Thank you! > On Sep 3, 2017, at 17:53, Dr. Matthias St. Pierre > wrote: > >> >> The 'RAND_add()/RAND_bytes()' pattern is broken >> === >> >> In OpenSSL, the classical way for the RNG consumer to add his

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

> > The 'RAND_add()/RAND_bytes()' pattern is broken > === > > In OpenSSL, the classical way for the RNG consumer to add his own randomness > is to call 'RAND_add()' before > calling 'RAND_bytes()'. If the new 'RAND_OpenSSL()' method (the >

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

7217 Oracle Australia -Original Message- From: Blumenthal, Uri - 0553 - MITLL [mailto:u...@ll.mit.edu] Sent: Thursday, 31 August 2017 12:27 AM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Plea for a new public OpenSSL RNG API On 8/30/17, 00:59, "openssl-dev on behalf of

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

> -Ursprüngliche Nachricht- > Von: openssl-dev [mailto:openssl-dev-boun...@openssl.org] Im Auftrag von > Blumenthal, Uri - 0553 - MITLL > Gesendet: Mittwoch, 30. August 2017 17:23 > An: openssl-dev@openssl.org > Betreff: Re: [openssl-dev] Plea for a new publ

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

>> I would do exactly the opposite. “Normal” entropy is fetched from the default sources (/dev/urandom). But >> when a sensitive (aka long-term) keys are generated, a (portable :) hardware RNG is plugged in and used with >> RAND_add() equivalent. Reason – in my setup reliable trusted

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

> > We have a similar situation, on a small hardware device with little > own entropy > > but with a smartcard reader. > > Yes, but in most cases you cannot count on the smartcard (or smartcard-like > device) being in the reader. > Which is why in my opinion this is an ideal case for

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

On 8/30/17, 00:59, "openssl-dev on behalf of Paul Dale" wrote: >My thoughts are that the new RNG API should be made public once it has >been properly designed. We've a chance to get this right, let's take the > time >

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

> -Ursprüngliche Nachricht- > Von: openssl-dev [mailto:openssl-dev-boun...@openssl.org] Im Auftrag von Matt > Caswell > Gesendet: Dienstag, 29. August 2017 16:36 > An: openssl-dev@openssl.org > Betreff: Re: [openssl-dev] Plea for a new public OpenSSL RNG API > >

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

> I realize that reseed() not only mixes my “additional input” but also > replaces the entire state. NIST does > not specify interface to “just” mix the “additional input” into the state > without replacing the whole state > with some fresh entropy by calling Get_entropy_input(). Maybe we can

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

>> I *don’t want* OpenSSL to make *any* estimation of the amount of provided >> entropy. All I want it to do is to mix these bits into the RNG state. It’s >> *my* business how much entropy I’m providing – but I don’t want OpenSSL to >> make any decision regarding pull from other entropy sources

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

➢ > Sure I can. Because the DRBG seeds from the system anyway ➢ You can't assume that will work for all users. And for places where the systesm doen’t have enough randomness, there is nothing we can do. -- openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

On Tue, Aug 29, 2017 at 08:38:09PM +, Blumenthal, Uri - 0553 - MITLL wrote: > > If, based on its value, OpenSSL may decide that it now got “enough” entropy > > and doesn’t need to > > pull more from other sources before serving randomness to requestors – then > > it is harmful. > >

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

➢ But now we just ignore it and assume every bit with get contains 1 ➢ bit of randomness and we're sundenly seriously overestimating the ➢ amount of randomness we're getting. This is a documented public API, ➢ you can't just go and ignore this parameter. Sure I can. Because the

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

> If, based on its value, OpenSSL may decide that it now got “enough” entropy > and doesn’t need to > pull more from other sources before serving randomness to requestors – then > it is harmful. > “Over-confidence” in this value by the caller can negatively impact the > quality of the produced

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

On Tue, Aug 29, 2017 at 06:50:37PM +, Blumenthal, Uri - 0553 - MITLL wrote: > On 8/29/17, 12:45, "openssl-dev on behalf of Salz, Rich via openssl-dev" > wrote: > > ➢ An other problem with the current implemenation is

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

On 8/29/17, 15:22, "openssl-dev on behalf of Salz, Rich via openssl-dev" wrote: ➢ I’d like to suggest that any approach other than “immediately mix the received randomness into the RNG state” is bad. If a user does

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

In message <168cef3c-d655-47bf-9874-048308154...@ll.mit.edu> on Tue, 29 Aug 2017 19:04:48 +, "Blumenthal, Uri - 0553 - MITLL" said: uri> uri> Could you please be more specific wrt. DRBG organization that in your opinion could impact the UI? uri> uri> Are you

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

➢ I’d like to suggest that any approach other than “immediately mix the received randomness into the RNG state” is bad. If a user does RAND_add() now, as opposed to 100 source code lines before, there may be a reason for that. I think the only way to do that in the DRBG model is to treat it

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

On 8/29/17, 11:33, "openssl-dev on behalf of Salz, Rich via openssl-dev" wrote: Could you please be more specific wrt. DRBG organization that in your opinion could impact the UI? > From your use-case:

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

IMHO this interface is a way for the user to improve the quality of the randomness it would get from the given RNG, *not* to replace (or diminish) its other sources. My proposal is to abolish this parameter, especially since now it is simply ignored (and IMHO – for a good reason). That's a

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

uri> Could you please be more specific wrt. DRBG organization that in your opinion could impact the UI? Are you talking about the UI API or something else? No-no-no, just the UI API. I used the term “UI” to emphasize that this is the “public” part of the API, exposed to the

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

➢ IMHO this interface is a way for the user to improve the quality of the randomness it would get from the given RNG, *not* to replace (or diminish) its other sources. My proposal is to abolish this parameter, especially since now it is simply ignored (and IMHO – for a good reason). We

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

On 08/29/2017 01:50 PM, Blumenthal, Uri - 0553 - MITLL wrote: > IMHO this interface is a way for the user to improve the quality of the > randomness it would get from the given RNG, *not* to replace (or diminish) > its other sources. My proposal is to abolish this parameter, especially since >

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

On 8/29/17, 12:45, "openssl-dev on behalf of Salz, Rich via openssl-dev" wrote: ➢ An other problem with the current implemenation is that the ➢ randomness parameter that's now given to RAND_add() is just ➢

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

➢ An other problem with the current implemenation is that the ➢ randomness parameter that's now given to RAND_add() is just ➢ ignored, it assumes it's the same as the length. For what it’s worth, this was done deliberately, make RAND_add and RAND_seed equivalent. I am skeptical of

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

On Tue, Aug 29, 2017 at 01:05:21PM +, Dr. Matthias St. Pierre wrote: > > Currently it's only possible to customize the callbacks but not the > deterministic algorithm. IMHO this is sufficient for the needs of a standard > OpenSSL user who only wants control over the entropy source. A true

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

sl-dev@openssl.org > > Betreff: Re: [openssl-dev] Plea for a new public OpenSSL RNG API > > > > > > On 29/08/17 10:45, Dr. Matthias St. Pierre wrote > > > ... > > > The 'RAND_add()/RAND_bytes()' pattern is broken > > > =

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

I actually plan to work on most of not all the things you mention. This will probably result in the API changing before it's made public. I'm probably slow, so please be patient. Kurt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

Could you please be more specific wrt. DRBG organization that in your opinion could impact the UI? From your use-case: you want to add entropy into a specific DRBG. You want to push it, as opposed to the DRBG “pull when needed” model. That’s an additional API. Also from your

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

Could you please be more specific wrt. DRBG organization that in your opinion could impact the UI? NIST 90Ar1 seems specific enough on what functionality DRBG can provide to users, and it doesn't seem like a very elaborate or rich interface. Why would it change, regardless of what you may

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

On 29/08/17 15:02, Salz, Rich via openssl-dev wrote: > > dev asap. If there are problems with it we can always revert it before > it makes it into a release. > > Someone on the OMC called that “flip-flopping” and seemed to be against this > kind of thing. > > If we are going to have

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

dev asap. If there are problems with it we can always revert it before it makes it into a release. Someone on the OMC called that “flip-flopping” and seemed to be against this kind of thing. If we are going to have an additional API, then we should at least see a draft of the header

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

In message <3a54fcefd17d4735920426d21b3b8...@ex13.ncp.local> on Tue, 29 Aug 2017 13:39:02 +, "Dr. Matthias St. Pierre" said: Matthias.St.Pierre> Just a sudden inspiration: If the RAND_DRBG becomes a truly independent API it might be better to strip the RAND_

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

On Tue, Aug 29, 2017, Richard Levitte wrote: > I'm late in the game, having only followed the development very > superficially... > > If I understand correctly, the RAND_DRBG API is really a completely > separate API that has nothing to do with the RAND_METHOD API pers se, > i.e. any association

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

In message on Tue, 29 Aug 2017 13:27:20 +, "Dr. Matthias St. Pierre" said: Matthias.St.Pierre> > Essentially, the argument for your last remark is in-structure vtable Matthias.St.Pierre> > vs refered to

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

> Essentially, the argument for your last remark is in-structure vtable > vs refered to vtable. I tend to prefer the latter (and that's the > usual OpenSSL pattern too, even though there are exceptions). You are the experts and much more familiar with the code then I am. My role was only to

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

In message <0e062727611c44bb8039170bbec11...@ex13.ncp.local> on Tue, 29 Aug 2017 13:05:21 +, "Dr. Matthias St. Pierre" said: Matthias.St.Pierre> > Frankly, I cannot see anything wrong with making that a public API. I Matthias.St.Pierre> > wonder, though, if

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

I'm late in the game, having only followed the development very superficially... If I understand correctly, the RAND_DRBG API is really a completely separate API that has nothing to do with the RAND_METHOD API pers se, i.e. any association between the two is more or less "accidental"? Frankly, I

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

> -Ursprüngliche Nachricht- > Von: openssl-dev [mailto:openssl-dev-boun...@openssl.org] Im Auftrag von Matt > Caswell > Gesendet: Dienstag, 29. August 2017 12:17 > An: openssl-dev@openssl.org > Betreff: Re: [openssl-dev] Plea for a new public OpenSSL RNG API > >

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

On 29/08/17 10:45, Dr. Matthias St. Pierre wrote > Currently, the OpenSSL core members seem to be reluctant to make the > API public, at least at this early stage. I understand Rich Salz's > viewpoint that this requires a thorough discussion, because a public > interface can't be easily changed