"Blumenthal, Uri - 0553 - MITLL" <u...@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) -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev