[openssl-dev] Work on a new RNG for OpenSSL
Steffen Nurpmeso
steffen at sdaoden.eu
Thu Aug 24 13:47:01 UTC 2017
"Blumenthal, Uri - 0553 - MITLL" <uri at ll.mit.edu> 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)
More information about the openssl-dev
mailing list