Re: Work on a new RNG for OpenSSL

"Blumenthal, Uri - 0553 - MITLL" <[email protected]> wrote:
 |>    So I guess you want an interface that can both add things to the
 |>   "entropy" pool, and to the "additional data" pool? It shouldn't
 |>    be that hard, I'll try to come up with some proposal soon.
 |  
 |I’d say the interface that  Rich Salz proposed would be good enough:
 |
 |> …  But I think a new API, RAND_add_ex() that took a flag that had \
 |> values like
 |> RAND_ADD_GLOBAL, RAND_ADD_LOCAL, RAND_ADD_PRIVATE,
 |> RAND_LOCAL_PRIVATE indicating which to seed.     Thoughts?
 |
 |It exposes what’s necessary, but nothing more. Another benefit – malicious \
 |input would not compromise the entropy pool.
 |
 |> We should think carefully about what API’s we are exposing, and might \
 |> want to wait for 1.1.2
 |
 |Nothing wrong with thinking about what API to expose, and how. Since \
 |1.1.1 is what’s currently being shaped – there’s no reason to postpone \
 |that thinking. Especially since the RNG/DRBG work is being done on \
 |1.1.1 now, and this is a part of it.

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.
But i am not writing a multithreaded server with the need for
performance comparisons, RAND_bytes() is good enough for us.
(And since OpenSSL is optional we still have to do some searching
around to find a PRNG anyway, with a builtin arc4 fallback.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev