Good evening.
Jakob Bohm via openssl-users wrote in <95bceb59-b299-015a-f9c2-e2487a699\
8ad@xxxxxxxxxx>:
|Small corrections below:
|
|On 07/01/2019 19:31, Steffen Nurpmeso wrote:
|
||...
|||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 have to say i struggle with the OpenSSL project release
announcements. Really. I see a short mail which simply points
users to some (granted super duper) web site (with custom fonts
and such -- it must look fantastic on such a tablet thing that
i do not own!), and on these pages, which i, unfortunately and
until now, over and over again look at, ... to see nothing.
I mean, OpenSSL is such a vivid part of the infrastructure, top
that with security, of the world, it is used a billion of times
each and every day, and how many people really now about the
details inside this library with the terrible interface names (a
few minutes ago i discovered the also new ADMISSIONS.pod
documentation, and this is a statement for a language with
namespaces and method-on-object not instance-on-function; i always
think by myself that some university should perform neurological
science on what looking at
const STACK_OF(ADMISSIONS) *ADMISSION_SYNTAX_get0_contentsOfAdmissions(const ADMISSION_SYNTAX *as);
from 9 to 5 (or 14 to 04 or whatever)/365-52 actually causes, how
do you say that in english?, what damages to the brain it causes,
anyway.)
The thing is, i have just seen the release candidate announcement
for bash 5.0 a while ago, and know what my own release message
will (have to) look like.
I did know nothing of all that.
|||> 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
...
||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.
I seem to know that for things like save transport.
I have for example suppressed adding the
for(u.i = 5 * sizeof(a_aux_rand->b8); u.i != 0; --u.i)
a_aux_rand_get8();
which follows the unscientific seeding. (And which likely is also
unscientific given that we have been seeded with random data
rather than with key/nonce ... whatever.)
|Enjoy
Not really! For example i read
The reseeding default values are applied only during creation of
a DRBG instance. To ensure that they are applied to the global
and thread-local DRBG instances (<master>, resp. <public> and
<private>), it is necessary to call
RAND_DRBG_set_reseed_defaults() before creating any thread and
before calling any cryptographic routines that obtain random
data directly or indirectly.
Does this give me at least the promise that OPENSSL_init_ssl() can
be called without rendering RAND_DRBG_set_reseed_defaults(0,0,0,0)
effectively a useless call?
I see that said function may return error, but it seems that the
MAX_RESEED_INTERVAL it fails to accept is not a public variable!
I tend to do the much more expensive dance with
RAND_DRBG_get0_public() and RAND_DRBG_get0_master() and
individually applying RAND_DRBG_set_reseed_time_interval() as well
as RAND_DRBG_set_reseed_interval() on each of them.
Is this even allowed without calling OPENSSL_init_ssl() first?
--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
