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