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
