> |Both manpages got an update during the DRBG rewrite (by me) and I don't > |see any contradiction. You bring it to the point yourself: > > I had a superficial look yesterday, but i think i have to reread > them in total, anyway. Yes, please start with RAND(7) and RAND_DRBG(7). > 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. > 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 OpenSSL does not handle yet, you could theoretically register your own get_entropy callback for the master DRBG at application startup time. But if you don't have a better entropy source than OpenSSL, you are bound to fail, too. And isn't it better for your application to fail gracefully in this case than to provide snake oil security? HTH, Matthias P.S: As for automatic reseeding: There are potential issues when upgrading applications which do a fork and chroot from 1.1.0 to 1.1.1. Because in version 1.1.1, the application will reseed after fork, and the reseeding can fail if the application developer (or administrator) did not pay attention to provide a random device in the chroot jail. This was no problem with 1.1.0 and below, because the RNG never reseeded automatically. OpenSSL does everything to avoid such a chroot reseeding failure (#6432 and #7437). Also, on modern linux systems OpenSSL will prefer the getrandom system call which does not have this limitation of the random devices. https://github.com/openssl/openssl/pull/6432 https://github.com/openssl/openssl/pull/7437 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
