On 08/29/2017 05:17 AM, Matt Caswell wrote: > On 29/08/17 10:45, Dr. Matthias St. Pierre wrote >> Currently, the OpenSSL core members seem to be reluctant to make the >> API public, at least at this early stage. I understand Rich Salz's >> viewpoint that this requires a thorough discussion, because a public >> interface can't be easily changed and wrong decisions in the early >> phase can become a heavy burdon. > FWIW, I am not against making the API public although I too understand > Rich's reluctance. However it seems inevitable to me that sooner or > later this API will have to be made accessible and I see little benefit > in delaying that and plenty of reasons for doing it now (it only > frustrates those that know the functionality is there but can't get at > it :-)). There is always a risk with every API added that you get it > wrong, and then you are stuck with it for ever more. The only real > answers to this are: > > 1) Make sure you "design" your API to start with and get it reviewed
Definitely. It might be nice to see a high-level overview of what parts of the design changed while integrating the FIPS DRBG into the current form in master -- the global "rand_bytes" buffer and the removal of non-CTR implementation support are just a couple things that have been mentioned already in this thread. > 2) Encourage people to try the API while it is still in dev i.e. so we > can still change it before the final release. That also seems reasonable to me. I might go further and also propose that we seek a more stringent review standard than usual for this work, since it is such a critical subsystem, and the current level of review let a few things slip through unnoticed. > I'm not really convinced that keeping the API hidden now will mean that > it will be better in some future release. It just delays the point at > which we have the realisation of "if only we had designed it like *this* > it would have been soooo much better". Better is to make it public in > dev asap. If there are problems with it we can always revert it before > it makes it into a release. > >> The 'RAND_add()/RAND_bytes()' pattern is broken >> =============================================== >> >> In OpenSSL, the classical way for the RNG consumer to add his own >> randomness is to call 'RAND_add()' before calling 'RAND_bytes()'. If >> the new 'RAND_OpenSSL()' method (the "compatibility layer" hiding the >> public RAND_DRBG instance) is the default, then this does not work >> as expected anymore: >> >> The reason is that a call to 'RAND_add()' adds the provided >> randomness only to a global buffer ('rand_bytes'), from which it will >> be pulled during the next reseed. But no reseed is triggered. So the >> next RAND_bytes() call will be unaffected from the RAND_add(), which >> is not what the consumer expected. (The same holds for 'RAND_seed()', >> since 'drbg_seed()' only calls into 'drbg_add()') >> >> Reseeding of DRBGs occurs only at the following occasions: >> >> * immediately after a 'fork()' (new) * if the 'reseed_counter' >> exceeds the 'reseed_interval' * if 'RAND_DRBG_generate()' is called >> requesting 'prediction_resistance' * 'RAND_DRBG_reseed()' is called >> explicitely >> >> *Note:* Currently it looks like the situation is even worse: if >> 'RAND_add()' is called multiple times before a reseed occurs, then >> the result of the previous call is overwritten. >> >> Reseeding the 'DRBG' whenever the user calls 'RAND_add()' does not >> seem a good solution. It would be too expensive, in particular if >> system entropy is pulled for reseeding. Of course it is possible to >> fix this issue, but the DRBG provides for a much simpler solution: it >> lets the consumer contribute to the entropy of the internal state by >> providing additional input. If the user input contains entropy, >> that's fine, if it's "snake oil", no harm. The additional input is >> mixed into the internal state in just the same way as the entropy >> buffer using the 'ctr_df()' derivation function. One might think of >> the 'entropy' input as trusted randomness and 'adin' as untrusted >> randomness. >> >> For this reason, I would like to see the 'RAND_add()/RAND_bytes()' >> pattern deprecated and the 'RAND_DRBG_generate() with additional >> input' pattern advertised instead. > Deprecation itself would probably have to wait for a 1.2.0 release. We > have a binary/source compatibility guarantee for 1.1.0 which would not > be met for builds using "--api" or "no-deprecated". > > Is there a potential security vulnerability here? Applications using the > "old" APIs expect RAND_add() to behave in a particular way. If we have > silently changed this behaviour in 1.1.1 are they exposed? > Is there potential for vulnerability here? Yes. Whether there is actual vulnerability would require some careful analysis, and potentially input from people like Uri who have requirements for including TRBG input. -Ben
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev