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
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).
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
>> 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.
>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(),
>
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
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.
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
