[Cryptography] OpenSSL CSPRNG work

[Ben Laurie]

On 30 June 2017 at 18:02, Nemo <nemo at self-evident.org> wrote:

> Ben Laurie <benl at google.com> writes:
>
> > If you have effective mixing, what is the problem with mixing in
> > potentially non-random sources?
>
> That depends... Might any of those sources know something about your
> internal state?
>
>     https://blog.cr.yp.to/20140205-entropy.html


You're already broken if someone knows your internal state.


>
>
> But really this is just a detail. In the bigger picture, your question
> itself is wrong.
>

No it isn't.


>
> For cryptographic code, every additional piece of machinery makes the
> design harder to analyze rigorously. Every extra line of implementation
> is just another opportunity to make a subtle mistake.
>
> Unnecessary mechanism does not create "defense in depth"; it merely
> increases the attack surface.
>

This is an argument against mixing in _actually_ non-random sources, not
_potentially_ non-random sources. If they are also potentially random, then
they should be considered.


>
> Since every piece of complexity is a liability, the right question is
> not "Does this do any harm?", but rather "Is this necessary?" Each
> additional mechanism should contribute in a clear (ideally: provable)
> and meaningful (ideally: quantifiable) way to the security of the
> system. Otherwise, leave it out.


> Again, I humbly request that, whatever clever userspace machinery you
> devise, please disable it completely by default on any system with
> getrandom() / getentropy() / etc. (Key words are "by default". Sure,
> provide APIs for enabling whatever you want... But by default, please
> just use the system's provided mechanisms.)
>

I'm not making the decisions here - and its hard to tell from this thread
what decisions are being made!

A design proposal to comment on would be nice.


>
>  - Nemo
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170701/96b46170/attachment.html>