Just a notice for anyone interested,
In Red Hat Enterprise Linux 6 and 7 we disabled support for insecure
hashes for digital signatures. Basically signatures with MD5, MD4, MD2,
and SHA0 will fail verification by default. We could not switch off the
support for these weak hash algorithms
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
Discussion should be here on the mailing list.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Dear Rich,
On Mon, Jun 26, 2017 at 3:49 PM, Salz, Rich via openssl-dev <
openssl-dev@openssl.org> 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
> 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
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
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
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
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
> 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
On Mon, Jun 26, 2017 at 04:17:41PM +, 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
> > 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:
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
Hi there,
I'm building a dynamic engine to support a custom AES hardware module that I've
implemented in FPGA logic**, but after reading all available documentation, and
pouring over the source code, I'm still very confused about the following two
things.
1. How and where I should
> > 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 =
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
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.
> 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"?
--
> 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%
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
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/898
https://github.com/openssl/openssl/issues/2457
> 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
> 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
On 06/26/2017 11:51 AM, Salz, Rich wrote:
>> 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?
There are multiple dimensions to be considered, including reliability
and rate.
As
On Mon, Jun 26, 2017 at 11:29:19AM -0700, John Denker via openssl-dev wrote:
> 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
> As for reliability, I don't know what "mediocre" means. Usually security-
> critical code is correct or it's not. For a seed-source, either a lower
> bound on
> the amount of good "hard" randomness is available and reliable, or it's not.
We run in many environments, and I don't think it's
> > 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
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
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 yourself.
Code to do this exists, e.g.
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
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
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
32 matches
Mail list logo
