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