* getentropy() vs. getrandom() vs. arc4random()
@ 2022-06-15 14:24 Fernando Gont
2022-06-15 18:00 ` Adhemerval Zanella
0 siblings, 1 reply; 7+ messages in thread
From: Fernando Gont @ 2022-06-15 14:24 UTC (permalink / raw)
To: libc-help
Hi,
I'm currently trying to grasp the functional differences in the
different interfaces to generate pseudorandom numbers in different
platforms. And I was wondering if you could shed some light on some
questions I have.
** Brief Background: **
We're working on a document where we warn users about the security
implications of using rand() and random() to generate pseudorandom
numbers (in scenarios where cryptographically secure pseudorandom
numbers are needed).
So we want to recommend better PRNG options for different operating
systems. For example, in the case of OpenBSD, we recommend the use of
arc4random(3), which provides a higher-level interface than the
getentropy(2) system call.
However, we're unsure about what to recommend for the Linux case.
For the Linux case, I see that there's a lot of code using getrandom(2)
-- a syscall --, which is kind of complex/too-low-level. And I see that
Linux also has getentropy(3) library function, which is described in
random(7) as a "more portable interface the underlying PRNG devices".
So, for the Linux case, I feel tempted to recommend the usage of
getentropy(3) over getrandom(2), but since most code employs
getrandom(2), I'm not sure whether I'm missing something.
Any thoughts?
Aside, it seems that for OpenBSD, getentropy(2) is a "low-level"
syscall, while arc4random(3) is a high-level library function. But in
the case of Linux, getentropy(3) is a high-level library function
instead, while getrandom(2) is the low-level syscall. -- which means
that usage of these interfaces would probably not be consistent across
platforms.
Is this actually the case?
FWIW, if you're curious, the document we're working on is this one:
https://www.ietf.org/archive/id/draft-irtf-pearg-numeric-ids-generation-10.txt,
and the section that led me to start this thread is Section 7.1:
----- cut here ----
7.1. Category #1: Uniqueness (soft failure)
The requirement of uniqueness with a soft failure severity can be
complied with a Pseudo-Random Number Generator (PRNG).
NOTE:
Please see [RFC4086] regarding randomness requirements for
security.
While most systems provide access to a PRNG, many of such PRNG
implementations are not cryptographically secure, and therefore might
be statistically biased or subject to adversarial influence. For
example, ISO C [C11] rand(3) implementations are not
cryptographically secure.
NOTE:
Section 7.1 ("Uniform Deviates") of [Press1992] discusses the
underlying issues affecting ISO C [C11] rand(3) implementations.
On the other hand, a number of systems provide an interface to a
Cryptographically Secure PRNG (CSPRNG) [RFC8937] [RFC4086], which
guarantees high entropy, unpredictability, and good statistical
distribution of the random values generated. For example, GNU/
Linux's CSPRNG implementation is available via the getentropy(3)
interface [GETENTROPY], while OpenBSD's CSPRNG implementation is
available via the arc4random(3) and arc4random_uniform(3) interfaces
[ARC4RANDOM]. Where available, these CSPRNGs should be preferred
over e.g. POSIX [POSIX] random(3) or ISO C [C11] rand(3)
implementations.
In scenarios where a CSPRNG is not readily available to select
transient numeric identifiers of Category #1, a security and privacy
assessment of employing a regular PRNG should be performed,
supporting the implementation decision.
NOTE:
[Aumasson2018], [Press1992], and [Knuth1983], discuss theoretical
and practical aspects of pseudorandom numbers generation, and
provide guidance on how to evaluate PRNGs.
We note that since the premise is that collisions of transient
numeric identifiers of this category only leads to soft failures, in
many cases, the algorithm might not need to check the suitability of
a selected identifier (i.e., the suitable_id() function, described
below, could always return "true").
---- cut here ----
Thanks a lot in advance!
Regards,
--
Fernando Gont
e-mail: fernando@gont.com.ar
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: getentropy() vs. getrandom() vs. arc4random()
2022-06-15 14:24 getentropy() vs. getrandom() vs. arc4random() Fernando Gont
@ 2022-06-15 18:00 ` Adhemerval Zanella
2022-06-15 18:03 ` Noah Goldstein
2022-06-16 17:12 ` Fernando Gont
0 siblings, 2 replies; 7+ messages in thread
From: Adhemerval Zanella @ 2022-06-15 18:00 UTC (permalink / raw)
To: Fernando Gont; +Cc: Libc-help
> On 15 Jun 2022, at 07:24, Fernando Gont <fernando@gont.com.ar> wrote:
>
> Hi,
>
> I'm currently trying to grasp the functional differences in the different interfaces to generate pseudorandom numbers in different platforms. And I was wondering if you could shed some light on some questions I have.
>
>
> ** Brief Background: **
>
> We're working on a document where we warn users about the security implications of using rand() and random() to generate pseudorandom numbers (in scenarios where cryptographically secure pseudorandom numbers are needed).
>
> So we want to recommend better PRNG options for different operating systems. For example, in the case of OpenBSD, we recommend the use of arc4random(3), which provides a higher-level interface than the getentropy(2) system call.
>
> However, we're unsure about what to recommend for the Linux case.
>
> For the Linux case, I see that there's a lot of code using getrandom(2) -- a syscall --, which is kind of complex/too-low-level. And I see that Linux also has getentropy(3) library function, which is described in random(7) as a "more portable interface the underlying PRNG devices".
>
> So, for the Linux case, I feel tempted to recommend the usage of getentropy(3) over getrandom(2), but since most code employs getrandom(2), I'm not sure whether I'm missing something.
>
> Any thoughts?
>
> Aside, it seems that for OpenBSD, getentropy(2) is a "low-level" syscall, while arc4random(3) is a high-level library function. But in the case of Linux, getentropy(3) is a high-level library function instead, while getrandom(2) is the low-level syscall. -- which means that usage of these interfaces would probably not be consistent across platforms.
>
> Is this actually the case?
On glibc, getentropy and getrandom both end calling getrandom syscall although
with different flags. The getentropy calls getrandom without any flag which in turn
get entropy from /dev/urandom. The getrandom function allows us to specify
which source you use through GRND_RANDOM flag.
Also, getentropy current has a hard limit of maximum of 256 bytes and it is not
defined a cancelation entrypoint (so pthread_cancel does not act upon it).
So both functions drawn entropy direct from the kernel and with recent Linux
random number development to unify both random and urandom the difference
might ended up with just getentropy being a cancellation entrypoint.
The rand and random functions are both userspace only where caller should set
PRNG state and both returns predictable output based on the initial seed. On glibc
both are implemented with either a LGC or a polynomial generated, set by the
seed size. So the quality of the output will depend of the seed entropy and the
limitation of the polynomial used.
The arc4random is similar to getentropy and getrandom, but it tries to use kernel
entropy to initialize a PRNG. Also, the usual implementation that uses ChaCha20
(OpenBSD, FreeBSD) periodically feeds back kernel entropy to improve randomness.
The arc4random also provides some more guarantees, like fork-detection.
We are aiming to provide arc4random on new glibc version [1].
[1] https://patchwork.sourceware.org/project/glibc/list/?series=9540
>
>
> FWIW, if you're curious, the document we're working on is this one: https://www.ietf.org/archive/id/draft-irtf-pearg-numeric-ids-generation-10.txt, and the section that led me to start this thread is Section 7.1:
>
> ----- cut here ----
> 7.1. Category #1: Uniqueness (soft failure)
>
> The requirement of uniqueness with a soft failure severity can be
> complied with a Pseudo-Random Number Generator (PRNG).
>
> NOTE:
> Please see [RFC4086] regarding randomness requirements for
> security.
>
> While most systems provide access to a PRNG, many of such PRNG
> implementations are not cryptographically secure, and therefore might
> be statistically biased or subject to adversarial influence. For
> example, ISO C [C11] rand(3) implementations are not
> cryptographically secure.
>
> NOTE:
> Section 7.1 ("Uniform Deviates") of [Press1992] discusses the
> underlying issues affecting ISO C [C11] rand(3) implementations.
>
> On the other hand, a number of systems provide an interface to a
> Cryptographically Secure PRNG (CSPRNG) [RFC8937] [RFC4086], which
> guarantees high entropy, unpredictability, and good statistical
> distribution of the random values generated. For example, GNU/
> Linux's CSPRNG implementation is available via the getentropy(3)
> interface [GETENTROPY], while OpenBSD's CSPRNG implementation is
> available via the arc4random(3) and arc4random_uniform(3) interfaces
> [ARC4RANDOM]. Where available, these CSPRNGs should be preferred
> over e.g. POSIX [POSIX] random(3) or ISO C [C11] rand(3)
> implementations.
>
> In scenarios where a CSPRNG is not readily available to select
> transient numeric identifiers of Category #1, a security and privacy
> assessment of employing a regular PRNG should be performed,
> supporting the implementation decision.
>
> NOTE:
> [Aumasson2018], [Press1992], and [Knuth1983], discuss theoretical
> and practical aspects of pseudorandom numbers generation, and
> provide guidance on how to evaluate PRNGs.
>
> We note that since the premise is that collisions of transient
> numeric identifiers of this category only leads to soft failures, in
> many cases, the algorithm might not need to check the suitability of
> a selected identifier (i.e., the suitable_id() function, described
> below, could always return "true").
> ---- cut here ----
>
> Thanks a lot in advance!
>
> Regards,
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: getentropy() vs. getrandom() vs. arc4random()
2022-06-15 18:00 ` Adhemerval Zanella
@ 2022-06-15 18:03 ` Noah Goldstein
2022-06-15 20:29 ` Adhemerval Zanella
2022-06-16 17:12 ` Fernando Gont
1 sibling, 1 reply; 7+ messages in thread
From: Noah Goldstein @ 2022-06-15 18:03 UTC (permalink / raw)
To: Adhemerval Zanella; +Cc: Fernando Gont, Libc-help
On Wed, Jun 15, 2022 at 11:01 AM Adhemerval Zanella via Libc-help
<libc-help@sourceware.org> wrote:
>
>
>
> > On 15 Jun 2022, at 07:24, Fernando Gont <fernando@gont.com.ar> wrote:
> >
> > Hi,
> >
> > I'm currently trying to grasp the functional differences in the different interfaces to generate pseudorandom numbers in different platforms. And I was wondering if you could shed some light on some questions I have.
> >
> >
> > ** Brief Background: **
> >
> > We're working on a document where we warn users about the security implications of using rand() and random() to generate pseudorandom numbers (in scenarios where cryptographically secure pseudorandom numbers are needed).
> >
> > So we want to recommend better PRNG options for different operating systems. For example, in the case of OpenBSD, we recommend the use of arc4random(3), which provides a higher-level interface than the getentropy(2) system call.
> >
> > However, we're unsure about what to recommend for the Linux case.
> >
> > For the Linux case, I see that there's a lot of code using getrandom(2) -- a syscall --, which is kind of complex/too-low-level. And I see that Linux also has getentropy(3) library function, which is described in random(7) as a "more portable interface the underlying PRNG devices".
> >
> > So, for the Linux case, I feel tempted to recommend the usage of getentropy(3) over getrandom(2), but since most code employs getrandom(2), I'm not sure whether I'm missing something.
> >
> > Any thoughts?
> >
> > Aside, it seems that for OpenBSD, getentropy(2) is a "low-level" syscall, while arc4random(3) is a high-level library function. But in the case of Linux, getentropy(3) is a high-level library function instead, while getrandom(2) is the low-level syscall. -- which means that usage of these interfaces would probably not be consistent across platforms.
> >
> > Is this actually the case?
>
> On glibc, getentropy and getrandom both end calling getrandom syscall although
> with different flags. The getentropy calls getrandom without any flag which in turn
> get entropy from /dev/urandom. The getrandom function allows us to specify
> which source you use through GRND_RANDOM flag.
>
> Also, getentropy current has a hard limit of maximum of 256 bytes and it is not
> defined a cancelation entrypoint (so pthread_cancel does not act upon it).
>
> So both functions drawn entropy direct from the kernel and with recent Linux
> random number development to unify both random and urandom the difference
> might ended up with just getentropy being a cancellation entrypoint.
>
> The rand and random functions are both userspace only where caller should set
> PRNG state and both returns predictable output based on the initial seed. On glibc
> both are implemented with either a LGC or a polynomial generated, set by the
> seed size. So the quality of the output will depend of the seed entropy and the
> limitation of the polynomial used.
>
> The arc4random is similar to getentropy and getrandom, but it tries to use kernel
> entropy to initialize a PRNG. Also, the usual implementation that uses ChaCha20
> (OpenBSD, FreeBSD) periodically feeds back kernel entropy to improve randomness.
> The arc4random also provides some more guarantees, like fork-detection.
>
> We are aiming to provide arc4random on new glibc version [1].
>
> [1] https://patchwork.sourceware.org/project/glibc/list/?series=9540
Are there any blockers to this at the moment?
Wouldn't minding have some time before 2.36 to possibly look into the
x86_64 implementations.
>
> >
> >
> > FWIW, if you're curious, the document we're working on is this one: https://www.ietf.org/archive/id/draft-irtf-pearg-numeric-ids-generation-10.txt, and the section that led me to start this thread is Section 7.1:
> >
> > ----- cut here ----
> > 7.1. Category #1: Uniqueness (soft failure)
> >
> > The requirement of uniqueness with a soft failure severity can be
> > complied with a Pseudo-Random Number Generator (PRNG).
> >
> > NOTE:
> > Please see [RFC4086] regarding randomness requirements for
> > security.
> >
> > While most systems provide access to a PRNG, many of such PRNG
> > implementations are not cryptographically secure, and therefore might
> > be statistically biased or subject to adversarial influence. For
> > example, ISO C [C11] rand(3) implementations are not
> > cryptographically secure.
> >
> > NOTE:
> > Section 7.1 ("Uniform Deviates") of [Press1992] discusses the
> > underlying issues affecting ISO C [C11] rand(3) implementations.
> >
> > On the other hand, a number of systems provide an interface to a
> > Cryptographically Secure PRNG (CSPRNG) [RFC8937] [RFC4086], which
> > guarantees high entropy, unpredictability, and good statistical
> > distribution of the random values generated. For example, GNU/
> > Linux's CSPRNG implementation is available via the getentropy(3)
> > interface [GETENTROPY], while OpenBSD's CSPRNG implementation is
> > available via the arc4random(3) and arc4random_uniform(3) interfaces
> > [ARC4RANDOM]. Where available, these CSPRNGs should be preferred
> > over e.g. POSIX [POSIX] random(3) or ISO C [C11] rand(3)
> > implementations.
> >
> > In scenarios where a CSPRNG is not readily available to select
> > transient numeric identifiers of Category #1, a security and privacy
> > assessment of employing a regular PRNG should be performed,
> > supporting the implementation decision.
> >
> > NOTE:
> > [Aumasson2018], [Press1992], and [Knuth1983], discuss theoretical
> > and practical aspects of pseudorandom numbers generation, and
> > provide guidance on how to evaluate PRNGs.
> >
> > We note that since the premise is that collisions of transient
> > numeric identifiers of this category only leads to soft failures, in
> > many cases, the algorithm might not need to check the suitability of
> > a selected identifier (i.e., the suitable_id() function, described
> > below, could always return "true").
> > ---- cut here ----
> >
> > Thanks a lot in advance!
> >
> > Regards,
> > --
> > Fernando Gont
> > e-mail: fernando@gont.com.ar
> > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: getentropy() vs. getrandom() vs. arc4random()
2022-06-15 18:03 ` Noah Goldstein
@ 2022-06-15 20:29 ` Adhemerval Zanella
0 siblings, 0 replies; 7+ messages in thread
From: Adhemerval Zanella @ 2022-06-15 20:29 UTC (permalink / raw)
To: Noah Goldstein, Florian Weimer; +Cc: Fernando Gont, Libc-help
> On 15 Jun 2022, at 11:03, Noah Goldstein <goldstein.w.n@gmail.com> wrote:
>
> On Wed, Jun 15, 2022 at 11:01 AM Adhemerval Zanella via Libc-help
> <libc-help@sourceware.org <mailto:libc-help@sourceware.org>> wrote:
>>
>>
>>
>>> On 15 Jun 2022, at 07:24, Fernando Gont <fernando@gont.com.ar> wrote:
>>>
>>> Hi,
>>>
>>> I'm currently trying to grasp the functional differences in the different interfaces to generate pseudorandom numbers in different platforms. And I was wondering if you could shed some light on some questions I have.
>>>
>>>
>>> ** Brief Background: **
>>>
>>> We're working on a document where we warn users about the security implications of using rand() and random() to generate pseudorandom numbers (in scenarios where cryptographically secure pseudorandom numbers are needed).
>>>
>>> So we want to recommend better PRNG options for different operating systems. For example, in the case of OpenBSD, we recommend the use of arc4random(3), which provides a higher-level interface than the getentropy(2) system call.
>>>
>>> However, we're unsure about what to recommend for the Linux case.
>>>
>>> For the Linux case, I see that there's a lot of code using getrandom(2) -- a syscall --, which is kind of complex/too-low-level. And I see that Linux also has getentropy(3) library function, which is described in random(7) as a "more portable interface the underlying PRNG devices".
>>>
>>> So, for the Linux case, I feel tempted to recommend the usage of getentropy(3) over getrandom(2), but since most code employs getrandom(2), I'm not sure whether I'm missing something.
>>>
>>> Any thoughts?
>>>
>>> Aside, it seems that for OpenBSD, getentropy(2) is a "low-level" syscall, while arc4random(3) is a high-level library function. But in the case of Linux, getentropy(3) is a high-level library function instead, while getrandom(2) is the low-level syscall. -- which means that usage of these interfaces would probably not be consistent across platforms.
>>>
>>> Is this actually the case?
>>
>> On glibc, getentropy and getrandom both end calling getrandom syscall although
>> with different flags. The getentropy calls getrandom without any flag which in turn
>> get entropy from /dev/urandom. The getrandom function allows us to specify
>> which source you use through GRND_RANDOM flag.
>>
>> Also, getentropy current has a hard limit of maximum of 256 bytes and it is not
>> defined a cancelation entrypoint (so pthread_cancel does not act upon it).
>>
>> So both functions drawn entropy direct from the kernel and with recent Linux
>> random number development to unify both random and urandom the difference
>> might ended up with just getentropy being a cancellation entrypoint.
>>
>> The rand and random functions are both userspace only where caller should set
>> PRNG state and both returns predictable output based on the initial seed. On glibc
>> both are implemented with either a LGC or a polynomial generated, set by the
>> seed size. So the quality of the output will depend of the seed entropy and the
>> limitation of the polynomial used.
>>
>> The arc4random is similar to getentropy and getrandom, but it tries to use kernel
>> entropy to initialize a PRNG. Also, the usual implementation that uses ChaCha20
>> (OpenBSD, FreeBSD) periodically feeds back kernel entropy to improve randomness.
>> The arc4random also provides some more guarantees, like fork-detection.
>>
>> We are aiming to provide arc4random on new glibc version [1].
>>
>> [1] https://patchwork.sourceware.org/project/glibc/list/?series=9540
>
> Are there any blockers to this at the moment?
>
> Wouldn't minding have some time before 2.36 to possibly look into the
> x86_64 implementations.
I think the last part is what missing some review (the TCB optimization to make it
lockless) and I am also waiting some feedback from Florian, since my proposal
is similar but uses a different strategy than his previous one.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: getentropy() vs. getrandom() vs. arc4random()
2022-06-15 18:00 ` Adhemerval Zanella
2022-06-15 18:03 ` Noah Goldstein
@ 2022-06-16 17:12 ` Fernando Gont
2022-06-16 17:27 ` Yann Droneaud
1 sibling, 1 reply; 7+ messages in thread
From: Fernando Gont @ 2022-06-16 17:12 UTC (permalink / raw)
To: Adhemerval Zanella; +Cc: Libc-help
Hello, Adhemerval,
Thanks a lot for your response! In-line....
On 15/6/22 15:00, Adhemerval Zanella wrote:
[....]
>> Is this actually the case?
>
> On glibc, getentropy and getrandom both end calling getrandom syscall
> although with different flags. The getentropy calls getrandom without
> any flag which in turn get entropy from /dev/urandom. The getrandom
> function allows us to specify which source you use through
> GRND_RANDOM flag.
>
> Also, getentropy current has a hard limit of maximum of 256 bytes and
> it is not defined a cancelation entrypoint (so pthread_cancel does
> not act upon it).
>
> So both functions drawn entropy direct from the kernel and with
> recent Linux random number development to unify both random and
> urandom the difference might ended up with just getentropy being a
> cancellation entrypoint.
One question here:
If getentropy() ends up calling getrandom() to read from /dev/urandom,
my understanding is that it would never block. Is that correct?
However, the manpage for getentropy(3) says:
A call to getentropy() may block if the system has just booted
and the kernel has not yet collected enough randomness to
initialize the entropy pool. In this case, getentropy() will
keep blocking even if a signal is handled, and will return only
once the entropy pool has been initialized.
Am I missing something?
Aside, from what I read in the manual pages, getrandom()/getentropy()
e.g. does not result in a uniform distribution. So, in other words, one
can not really use them to comply with the requirements in RFC4086
(i.e., as a cryptographically secure PRNG), but rather only use it as a
building block to build such a CSPRNG?
Thanks!
Regards,
--
Fernando Gont
e-mail: fernando@gont.com.ar
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: getentropy() vs. getrandom() vs. arc4random()
2022-06-16 17:12 ` Fernando Gont
@ 2022-06-16 17:27 ` Yann Droneaud
2022-06-16 17:46 ` Adhemerval Zanella
0 siblings, 1 reply; 7+ messages in thread
From: Yann Droneaud @ 2022-06-16 17:27 UTC (permalink / raw)
To: Fernando Gont, Adhemerval Zanella; +Cc: Libc-help
Hi,
Le 16/06/2022 à 19:12, Fernando Gont a écrit :
>
> On 15/6/22 15:00, Adhemerval Zanella wrote:
> [....]
>>> Is this actually the case?
>>
>> On glibc, getentropy and getrandom both end calling getrandom syscall
>> although with different flags. The getentropy calls getrandom without
>> any flag which in turn get entropy from /dev/urandom. The getrandom
>> function allows us to specify which source you use through
>> GRND_RANDOM flag.
>>
>> Also, getentropy current has a hard limit of maximum of 256 bytes and
>> it is not defined a cancelation entrypoint (so pthread_cancel does
>> not act upon it).
>>
>> So both functions drawn entropy direct from the kernel and with
>> recent Linux random number development to unify both random and
>> urandom the difference might ended up with just getentropy being a
>> cancellation entrypoint.
>
> One question here:
> If getentropy() ends up calling getrandom() to read from /dev/urandom,
> my understanding is that it would never block. Is that correct?
>
getrandom() syscall will block until the kernel CSPRNG is fully
initialized (gathered enough entropy) after system boot.
After that, it will never block and behave like /dev/urandom. The
blocking behavior is mostly a problem for PID 1.
> However, the manpage for getentropy(3) says:
> A call to getentropy() may block if the system has just booted
> and the kernel has not yet collected enough randomness to
> initialize the entropy pool. In this case, getentropy() will
> keep blocking even if a signal is handled, and will return only
> once the entropy pool has been initialized.
>
> Am I missing something?
>
>
> Aside, from what I read in the manual pages, getrandom()/getentropy()
> e.g. does not result in a uniform distribution. So, in other words,
> one can not really use them to comply with the requirements in RFC4086
> (i.e., as a cryptographically secure PRNG), but rather only use it as
> a building block to build such a CSPRNG?
>
Could you provide the part that state the output is not uniformly
distributed ?
Regards.
--
Yann Droneaud
OPTEYA
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: getentropy() vs. getrandom() vs. arc4random()
2022-06-16 17:27 ` Yann Droneaud
@ 2022-06-16 17:46 ` Adhemerval Zanella
0 siblings, 0 replies; 7+ messages in thread
From: Adhemerval Zanella @ 2022-06-16 17:46 UTC (permalink / raw)
To: Yann Droneaud; +Cc: Fernando Gont, Libc-help
> On 16 Jun 2022, at 10:27, Yann Droneaud <ydroneaud@opteya.com> wrote:
>
> Hi,
>
> Le 16/06/2022 à 19:12, Fernando Gont a écrit :
>>
>> On 15/6/22 15:00, Adhemerval Zanella wrote:
>> [....]
>>>> Is this actually the case?
>>>
>>> On glibc, getentropy and getrandom both end calling getrandom syscall
>>> although with different flags. The getentropy calls getrandom without
>>> any flag which in turn get entropy from /dev/urandom. The getrandom
>>> function allows us to specify which source you use through
>>> GRND_RANDOM flag.
>>>
>>> Also, getentropy current has a hard limit of maximum of 256 bytes and
>>> it is not defined a cancelation entrypoint (so pthread_cancel does
>>> not act upon it).
>>>
>>> So both functions drawn entropy direct from the kernel and with
>>> recent Linux random number development to unify both random and
>>> urandom the difference might ended up with just getentropy being a
>>> cancellation entrypoint.
>>
>> One question here:
>> If getentropy() ends up calling getrandom() to read from /dev/urandom, my understanding is that it would never block. Is that correct?
>>
>
> getrandom() syscall will block until the kernel CSPRNG is fully initialized (gathered enough entropy) after system boot.
>
> After that, it will never block and behave like /dev/urandom. The blocking behavior is mostly a problem for PID 1.
Yes, and getrandom does not *read* /dev/urandom in the sense that it uses a file
descriptor to do so (I think it is worth to make it clear).
And I think kernel is trying to improve this on recent releases, although I do not
know the current status.
>
>
>> However, the manpage for getentropy(3) says:
>> A call to getentropy() may block if the system has just booted
>> and the kernel has not yet collected enough randomness to
>> initialize the entropy pool. In this case, getentropy() will
>> keep blocking even if a signal is handled, and will return only
>> once the entropy pool has been initialized.
>>
>> Am I missing something?
>>
>>
>> Aside, from what I read in the manual pages, getrandom()/getentropy() e.g. does not result in a uniform distribution. So, in other words, one can not really use them to comply with the requirements in RFC4086 (i.e., as a cryptographically secure PRNG), but rather only use it as a building block to build such a CSPRNG?
>>
>
> Could you provide the part that state the output is not uniformly distributed ?
Indeed it is also new to me.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-06-16 17:46 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-15 14:24 getentropy() vs. getrandom() vs. arc4random() Fernando Gont
2022-06-15 18:00 ` Adhemerval Zanella
2022-06-15 18:03 ` Noah Goldstein
2022-06-15 20:29 ` Adhemerval Zanella
2022-06-16 17:12 ` Fernando Gont
2022-06-16 17:27 ` Yann Droneaud
2022-06-16 17:46 ` Adhemerval Zanella
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).