>> 1. What’s the default if “with-rand-seed” was not provided? All of the >> listed supported types? None of them? Some of them…? > > As the first bullet says, it’s “os”.
OK, thanks.
> As for the second part of your question, it is deliberately not answered.
> If you care, you’ll have to read the source. (It’s clean and easy to do so,
> now.) We’re not documenting everything.
I think it’s a bad approach to not document this important behavior. It has to
be security-analyzed, then frozen & published.
>>2. What is the order in which the seed sources are tried (both when
>>“with-random-seed” was and was not given)?
>
> Read the source.
Likewise. It has to be published, and the developers need to figure out the
right way here and commit to it (no pun intended).
>> 3. What should I do if I want a given source to be used in addition to the
>> other sources, regardless of whether openssl thinks it got “enough bits” of
>> randomness or not?
>
> Modify the source :)
Very bad answer.
When randomness is involved, adding more of diverse sources can only improve
the outcome. Therefore there must be a way to tell OpenSSL to *not* stop when
it got what it believe to be “enough” but mix in more from other sources. And
that mechanism must *not* be an individual hack – but a standard reviewed
maintained access method.
> For a few reasons, we’re deliberately not documenting all the details.
> Interested parties will have to read the source.
I have no problem reading the source code. I do have a problem with (a)
important decisions like this not “formalized” and documented, and (b)
mechanisms to tune the RNG seeding not provided and clearly and comprehensively
documented.
I urge the developers to reconsider.
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
