On 8/24/17, 09:45, "openssl-dev on behalf of Steffen Nurpmeso"
<openssl-dev-boun...@openssl.org on behalf of stef...@sdaoden.eu> wrote:
>> … But I think a new API,
>> RAND_add_ex() that took a flag
>> RAND_ADD_GLOBAL, RAND_ADD_LOCAL, RAND_ADD_PRIVATE,
>> RAND_LOCAL_PRIVATE indicating which to seed.
>
> If you say it and continue like that then let me wonder why the
> objects as such cannot be accessed like
>
> RAND_object_get(SPECIAL_CONSTANT_OR_NULL), or
> RAND_object_create(SPECIAL_CONSTANT_OR_NULL), plus
> RAND_object_bytes() and RAND_object_add(). And all the current
> could be macros or inline functions to the corresponding new
> object based functions.My take and motivation is this: - OpenSSL is designed to run on all kinds of architectures, CPU, and OS. Some have better entropy sources then others. - The current blog essentially says that regardless of how many RNGs you defined – if the first one provides “enough” entropy, other RNGs won’t be asked to contribute. Some applications may not want to rely on one RNG for tasks they consider critical. - Applications that need better entropy guarantees may want to contribute to the entropy pool by mixing in entropy from sources other than the default RNG. - NIST SP 800-90A Rev 1 understood this need and defined interface “Additional input” that can be applied to both reseeding and generation. Since not every application has such need, NIST made this interface optional. - OpenSSL is not developed with one specific application in mind, therefore it make sense to implement and provide that optional interface, allowing so applications to mix in randomness from whatever other sources they trust and have available. I personally see no harm if these RNG objects are made available to applications that need/use them. But my first priority is being able to add to the RNG entropy pool more randomness from a source I trust.
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
