Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

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 from my iPhone

> On Aug 21, 2017, at 20:06, Paul Dale  wrote:
> 
> 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 difficult to implement given all the out of order 
> execution and look ahead that CPUs do.   It requires a compromised RDRAND 
> instruction changing the behaviour of a subsequent XOR into a copy.  Not only 
> would it not be producing random bits but it would remove any randomness from 
> the bits you already have.
> 
> 
> Pauli
> -- 
> Oracle
> Dr Paul Dale | Cryptographer | Network Security & Encryption 
> Phone +61 7 3031 7217
> Oracle Australia
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

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). According to 
the author (as I understood him), not only RDRAND must be compromised (i.e., 
produce bad output), but the CPU would have to switch to a "special" processing 
mode when RDRAND instruction is detected. And this malicious CPU would have to 
understand how RNG is implemented in Linux, Mac, Windows, FreeBSD (at what 
point it calls RDRAND and what instructions follow)... And it's betting on 
RDRAND being the last in the chain of RNG inputs (otherwise it would wipe out 
previous entropy, but would in turn be replaced by something good from the next 
source). Also, usually mixing = XOR, but some prefer arithmetic addition - so 
RDRAND would be crafted to replace any subsequent operation to copy. Plus, it 
would have to track a bunch of the following instructions because it's common 
but not certain that the RDRAND output is mixed in immediately (in the very 
next instruction)...

To summarize, I don't have enough tin-foil for a hat of that size.

But regardless, a good solution IMHO is to offer an interface to mix in (add to 
the pool) whatever data the user wants as an additional input (in terms of SP 
800-90A that defined "additional input" to mix during reseeding and 
generation). That data could be an output of RDRAND, of an external RNG 
(including hardware TRNG), or... It would be up to the user to pick the 
additional source that he trusts. Also, nobody forces the user to employ that 
interface at all (just like on a decent OS nobody now is forced to use 
RAND_add()) - but it would be there for those who need/want it. 

Regards,
Uri

Sent from my iPhone

> On Aug 21, 2017, at 20:06, Paul Dale  wrote:
> 
> 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 difficult to implement given all the out of order 
> execution and look ahead that CPUs do.   It requires a compromised RDRAND 
> instruction changing the behaviour of a subsequent XOR into a copy.  Not only 
> would it not be producing random bits but it would remove any randomness from 
> the bits you already have.
> 
> 
> Pauli
> -- 
> Oracle
> Dr Paul Dale | Cryptographer | Network Security & Encryption 
> Phone +61 7 3031 7217
> Oracle Australia
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Paul Dale]

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 difficult to implement given all the out of order 
execution and look ahead that CPUs do.   It requires a compromised RDRAND 
instruction changing the behaviour of a subsequent XOR into a copy.  Not only 
would it not be producing random bits but it would remove any randomness from 
the bits you already have.


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Salz, Rich via openssl-dev]

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

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. One that is called when we
want to have entropy, the other that is called when we can use
additional data. The first would only be called by the global
DRBGs, the second by all DRBGs.

The DRBG now actually already uses callbacks to get entropy (and
a nonce), but none of that is exposed. So it would require
additional callbacks for additional data. We should probably just
add functions to set the defaults or something.


Kurt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

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

>From my point of view – adding these doesn’t add a whole lot, but it doesn’t 
>hurt. IMHO – add away. ;-)

>It might also use things like RDRAND / RDSEED which we don't trust.

Some don’t trust these, some think that they would add a good amount of 
entropy. I for one would certainly like to see the output of these mixed in. 
>From cryptography point of view, it cannot hurt, but may help a lot. Consider 
it as a lottery ticket you don’t have to pay for. ;-)

>So I guess you want an interface that can both add things to the
>"entropy" pool, and to the "additional data" pool?

That is correct. Especially because some of us have “real” nice/fancy hardware 
RNG (TRNG) available, and some like to mix in the output from RNGs on hardware 
tokens - maybe not as impressive as a “real” fancy TRNG, but as they say, every 
bit helps – in this case literally.

> It shouldn't be that hard, I'll try to come up with some proposal soon.

Thank you!!


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

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 NIST SP 90A is right, or you just bypass it 
> > completely.  We’re in the first camp.  
> 
> You mean NIST SP 800-90A, released Jan 2012 and withdrawn Jun 2015? With Rev 
> 1 *draft* currently available (released Jun 2015)?  ;-)
> 
> I’m glad you agree that “it is right”, because in our argument it supports my 
> side over yours. Let’s go through the 90A Rev 1 draft 
> http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf:
> 
> Page 11 Section 7 provides a functional model of a DRBG (Figure 1), clearly 
> showing “additional input” for both the Reseed Function and the Generate 
> Function.  The text says “… and may include additional optional sources, 
> including … additional input.”

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(), the TSC, ... It might also use things like RDRAND
/ RDSEED which we don't trust.

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.


Kurt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

>> 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 mean NIST SP 800-90A, released Jan 2012 and withdrawn Jun 2015? With Rev 1 
*draft* currently available (released Jun 2015)?  ;-)

I’m glad you agree that “it is right”, because in our argument it supports my 
side over yours. Let’s go through the 90A Rev 1 draft 
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf:

Page 11 Section 7 provides a functional model of a DRBG (Figure 1), clearly 
showing “additional input” for both the Reseed Function and the Generate 
Function.  The text says “… and may include additional optional sources, 
including … additional input.”

Page 12 Sec 7.2: “Additional input may also be provided during reseeding and 
when pseudorandom bits are requested.”

Page 22 Sec 8.7.2: “Additional input may optionally be provided to the reseed 
and generate functions during requests. The additional input may be obtained 
from inside or outside a cryptographic module, and may include secret or public 
information. ... Additional input is optional for both the DRBG and the 
consuming application, and the ability to enter additional input may or may not 
be included in an implementation.”

Same place: “The use of additional input may be a means of providing more 
entropy for the DRBG internal state that will increase assurance that the 
entropy requirements are met. If the additional input is kept secret and has 
sufficient entropy, the input can provide more assurance when recovering from 
the compromise of the entropy input, the seed or one or more DRBG internal 
states.”

The last quote explains exactly why people (myself included) may want that 
interface. The draft does not *mandate* making this interface available, but 
blesses it nonetheless. I’m one of those who falls into the category of “need 
to increase assurance that the entropy requirements are met”.

In other words, the standard clearly does allow the implementer to *include* 
additional input. The standard also allows the implementer to “weasel out” of 
it, but I cannot imagine why a security-cautious implementer would want to. 



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev