>> 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 move
➢ 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 per-threa
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 mai
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
>>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 chang
>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
>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 things
>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
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 indicating which to seed.
>
> If you say it and conti
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() mo
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 thi
"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 that Rich Salz propo
Okay: https://github.com/openssl/openssl/pull/4239
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Kehrer
To: "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"
On August 19, 2017 at 2:48:19 AM, Salz, Rich via openssl-dev (
openssl-dev@openssl.org) wrote:
I think the safest th
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 thing
>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 A
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
Sent
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). Accordi
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
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
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. On
>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(),
>clock_gettime
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 N
>> 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.
You
➢ 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?
At this point, you might as well just change the code to use getrandom() and
pass it through.
Either you accept that NIST SP
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 RAND_add_ex
"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 ☺ Did you read the b
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 cl
"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 first raised \
|it. I am
➢ 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 s
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.
Agree
On 2017-08-18 19:42, Kurt Roeckx wrote:
> 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
wrot
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 chan
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
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. The
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 th
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
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
> wrote:
>
> \
>> somewhere som
\
> 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
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. A
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 n
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 not about just reseeding, but what about when (if) we add oth
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
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 whic
>>> 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? Somethi
>>> 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 RAND_
>> 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
> 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
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, --with
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
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 that,
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 bytes/second is a DOS attack on it's ow
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 required.
>
> Plea
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 wrote:
>
>
> Peter Waltenberg wrote:
>> The next question you shou
ould compromise that. It's a very different problem from generating
good pseudo-random sequences and by it's nature doesn't lend itself well
to clean and elegant solutions.
Peter
From: Cory Benfield
To: openssl-dev@openssl.org
Date: 28/06/2017 17:15
Subject:
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 i
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 optim
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, does
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
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
ow
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-)seedi
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
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 m
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, b
> 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:
>> http://www.pcworld.com/article/2886432/tens-of-thousands-of-home-routers-at-risk-with-duplicate
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 boo
gic fairy dust like (/dev/hwrng) undoubtedly helps where it exists, but
you still have to apply it correctly to achieve the desired outcome.
Peter
From: John Denker via openssl-dev
To: "openssl-dev@openssl.org"
Date: 28/06/2017 12:19
Subject: Re: [openssl-dev] Wo
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 answer
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 be
nice to limit 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
Subject: Re: [
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
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 a
> 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: https://mta.openssl.org/mailman/listinfo/opens
--
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: [openssl-dev] Work on a new
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 kernel
, John Denker
Date: 28/06/2017 09:38
Subject: Re: [openssl-dev] Work on a new RNG for OpenSSL
Sent by:"openssl-dev"
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
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, thousand
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 adding
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 ; openssl-dev@openssl.org; Matt Caswell
Subject: Re: [openssl-dev] Work on a new RNG for OpenSSL
For windows RAND_bytes should just call CryptGenRandom
> I think we can get away with using OS-provided randomness directly in many
> common cases. /dev/urandom suffices once we know that the kernel RNG has
> been properly seeded. On FreeBSD, /dev/urandom blocks until the kernel RNG
> is seeded; on other systems maybe we have to make one read from
> 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 unsubscribe:
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 just
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 11:5
> 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
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 mod
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 per
> > 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 y
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 t
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 availabl
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
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 t
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 denial-of-s
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 wit
> > 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 RAND_set_rand
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 Bit
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
> 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.
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 bl
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
> https://github.com/openssl/openssl/issues/
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 answ
1 - 100 of 126 matches
Mail list logo
