On 06/29/2017 08:01 AM, I wrote:
> Some platforms are not secure and cannot be made secure.
This is relevant to the RNG discussion, and lots of other
stuff besides.
*) For example, you can use openssl rsa to generate a so-called
private key, but it will not actually be private (in any
practica
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 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 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
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
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 no
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.
https://en.wikipedia.org/wiki/RdRand#Sample_x86_asm_
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 fo
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 tha
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 hardnes
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
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 ven
12 matches
Mail list logo
