Good evening. Please excuse the late reply. Kurt Roeckx wrote in <20190104180735.GA25041@xxxxxxxxx>: |On Fri, Jan 04, 2019 at 02:48:48PM +0100, Steffen Nurpmeso wrote: |> Dr. Matthias St. Pierre wrote in <450169f8ca7c43d1841c4c8052e78c72@Ex13.\ |> ncp.local>: ... |>|2. If something goes wrong with PRNG initialization, that it will fail \ |>|hard rather than fall back to something less secure. And if so how \ |>|I detect such a failure. |>| |>|If the (re-)seeding fails, the DRBG enters an error state. When you \ |>|try to generate random bytes it will detect the error state and try |>|automatically to heal the error state by reinstantiating. But if \ |>|reseeding \ |>|fails, it will return and error code and not generate any pseudo random \ |>|bytes. |>| |>|Citing from the manual pages: |> ... |>| As a normal application developer, you do not have to worry about \ |>| any details, just use RAND_bytes(3) |>| to obtain random data. Having said that, there is one important rule \ |>| to obey: Always check the error |>| return value of RAND_bytes(3) and do not take randomness for granted. |>| |>| https://www.openssl.org/docs/man1.1.1/man7/RAND.html |> |> That is new however, _imho_. The wording of RAND_bytes(3) (still) |> says that "an error occurs [.if.] not [been] seeded with enough |> [data]", and RAND_status(3) returns 1 if the PRNG "has been seeded |> with enough data". So if it is seeded it is seeded, in my |> understanding anything further on up the road only mixes in noise |> (which likely will undergo further maths and be stirred into the |> pool, i have not looked, actually). I do not test RAND_bytes(3) |> return (yet), because i have ensured the PRNG is sufficiently |> seeded, and RAND_status(3) returns success, before RAND_bytes(3) |> is used the first time. | |For 1.1.0 and older that works, because they do not reseed. Since |1.1.1 it does reseed, and if the reseed fails, it will go to an |error state. So yes, this is new behavior. Thanks. Well this is good to know, i have to think about how i will deal with this. (I am also really interested and will look into OpenSSL to see if the abort() that seems to happen if the initial seed fails is in a linker-resolved constructor, and if not, why later failures do not also abort. Yes, while i am going, the full truth is that i do not like it, i do not like that possibly a constructor call is made for something that is possibly not needed, if it is done like that, that someone simply aborts because of a some internal PRNG, especially so if it is not in a constructor call and if errors can and are expected to be handled by PRNG users anyway, i do not like that the stuff is instantiated in all threads, which in addition requires forks handlers to be installed all over the place. Now, on NetBSD for example, and because of libraries i am linking in, i do have two complete sets of fork handlers and PRNG buffers all over the place, one for NetBSD LibC, one for OpenSSL. In my unfortunately not so humble opinion this looks like a modern white first world child. Including the postural defect. I am sorry for this rant. Yeah, i think OpenSSL even offers PRNG objects which i can use and control directly, and through this i regain a bit control of resource usage etc. Without rewriting software in order to pregenerate randoms in the main( manager) thread to pass them through to jobs in thread pools. Just look for those and do not use the TSD/fork-aware RAND_bytes(). But before i become a total troll.. the Linux kernel that drives the world from smallest to hugest has one internal entropy pool that feeds two public pools, whereas i the lucent little hobby server from user space get an armada of these. Wow. It is not your fault of course. I am sorry for this rant. Thanks for your answer.) How do i deal with this? Maybe i simply always use my builtin ARC4, it is so small, or upgrade to ChaCha20 or so, and add something like a Blake2 filter to protect that pool, and only serve the output of it. Or something. |The RAND_bytes and RAND_status manpages can clearly be improved. |Since you always have to check RAND_bytes's return value now, |RAND_status is mostly useless. Yes, in my opinion good documentation is hard, almost impossible. I am not using it, but i always enjoy reading the concise (concise! Says Mr. McIlroy.) yet helpful manuals from the really great guys, for example the Plan9 manuals regarding programming. Maybe a bit too concise for end-users, except academics. --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-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
