|
Small corrections below:
On 07/01/2019 19:31, Steffen Nurpmeso wrote: ... |> That is really bad. Of course you had to do it like this, and you |> surely have looked around to see what servers and other software |> which use OpenSSL do with the PRNG after forking (i.e., whether |> they reiterate the [RAND_file_name(),] RAND_load_file(), |> [:[RAND_add(),] RAND_status()], [RAND_write_file()] dance as |> documented, or not). | |I really don't understand your frustration: the new PRNG was designed |to relieve the application from the burden of seeding. It is easier to use, |not more complicated: No need to call RAND_add(), RAND_seed(), |RAND_load_file() and all this stuff. Just make sure the os entropy sources |are available and then simply use RAND_bytes(). But don't expect it to |succeed always. And may i ask, what to do if it fails? Try it in a loop a finite number of times, assuming it over-and-over detects it is in an error state and tries to reseed unless that succeeds, and bail if still without success thereafter? Talking about the only program in the public that i represent: i will not abort that one just because a PRNG fails to produce some bytes that this program uses for the purpose of, well, having some (pseudo but) random bytes; because: this is _completely_ disproportionate to the use cases of those random numbers. I guess the same could be said about UUIDS generated via PRNGs instead of how the standard defines them, etc. etc. Please do not say "use random(3) or rand(3)" now, please. So what to do? "Just failing" is precisely to allow you (and others) to do something sensible without the random bytes, such as using something less secure, or doing a polite error reporting to the user. |> I think i will move away from RAND_ then, nonetheless, and at |> least for the things i have control of. | |I don't think this is a good idea. In the case when there is no suitable \ |entropy |source, the OpenSSL RNG will fail to generate random bytes, indeed. |But how do you expect your application to seed the RNG properly in this |case? What is your application's entropy source? If you have one, which Yes, that is the problem. We do have several possibilities for VAL_RANDOM. Some of them only seed our builtin ARC4 implementation, which until now exposes the internal buffer as such (sufficient for our purpose yet). Examples of this are /dev/urandom, Linux getrandom as system call or library call, aehh... If that seeding fails, we create a completely unscientific homebrew seed via CLOCK_REALTIME or gettimeofday(2), whatever is available, wildly XORing through the buffer, further randomizing those weakly through the well-known algorithm from "Random number generators: good ones are hard to find", Park and Miller, Communications of the ACM, vol. 31, no. 10, October 1988, p. 1195 (a_aux_rand_weak()). This is the code: Note that since that ancient article, ARC4 was not only invented, but also found too insecure for modern use. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded |
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
