<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 08/29/2017 05:17 AM, Matt Caswell wrote:<br>
<blockquote type="cite"
cite="mid:2f79c2b6-560f-b245-b39d-dc4147d5ab44@openssl.org">
<pre wrap="">
On 29/08/17 10:45, Dr. Matthias St. Pierre wrote
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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
</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:2f79c2b6-560f-b245-b39d-dc4147d5ab44@openssl.org">
<pre wrap="">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.
</pre>
</blockquote>
<br>
That also seems reasonable to me.<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:2f79c2b6-560f-b245-b39d-dc4147d5ab44@openssl.org">
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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?
</pre>
</blockquote>
<br>
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.<br>
<br>
-Ben<br>
</body>
</html>