Re: RNG behavior by default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>  |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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux