>> 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