On 6/1/20 4:51 PM, Bruno Haible wrote:
>> I could add text along
>> these lines if this sounds like a good idea.
>
> Yes, that would sound good.
Done via the attached patch.
>From af3ff63e457ddb6ba29295e3d5b78a93d834cb8e Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Mon, 1 Jun 2020 17:02:54
Hi Paul,
> > No guidance regarding getrandom vs. crypto/gc-random any more?
>
> The main advantage of getrandom and/or getentropy over crypto/gc-random is the
> simpler API and lower maintenance/runtime overhead. crypto/gc-random is a
> better
> match if you're alre
On 6/1/20 12:01 PM, Bruno Haible wrote:
> No guidance regarding getrandom vs. crypto/gc-random any more?
The main advantage of getrandom and/or getentropy over crypto/gc-random is the
simpler API and lower maintenance/runtime overhead. crypto/gc-random is a better
match if you're alrea
Hi Paul,
> I installed the attached patch to the Gnulib doc, which attempts to address
> this
> along with the GRND_INSECURE business.
No guidance regarding getrandom vs. crypto/gc-random any more?
We have two modules, 'getrandom' and 'crypto/gc-random'
>> Also, it looks like (to me) getrandom may suffer VM rollback attacks.
>> So claiming a stream is high quality may be questionable if a reboot
>> produces the same stream.
> On which systems does getrandom() have this problem?
In theory, it could be any system. Even a hardware random-number gene
Hi Jeffrey,
I'm trying to state in simple-to-understand words what Simon said
about getrandom(), getentropy(), and libgcrypt.
If you have a better wording, please submit a patch.
> Nowadays it may be prudent to simply state the data returned from the
> prng should be treated as a seed and not us
On Sun, May 31, 2020 at 3:02 PM Bruno Haible wrote:
>
> Hi Simon,
>
> Thanks for your insights.
>
> > Historically, the problem is that for cryptographic purposes,
> > /dev/random and /dev/urandom can be a really bad choice on many
> > platforms. This has probably been improved over the years, es
Hi Simon,
Thanks for your insights.
> Historically, the problem is that for cryptographic purposes,
> /dev/random and /dev/urandom can be a really bad choice on many
> platforms. This has probably been improved over the years, especially
> on the most relevant platforms, but still
Indeed. Even
There is a lot to be said about randomness, but for the purpose of
getrandom() and getentropy(), which to my knowledge aren't globally
standardized (de-factor or otherwise) and well-specified what semantics
re cryptographic properties they should have, I agree it make sense to
keep the implementati
On Sun, May 31, 2020 at 7:23 AM Bruno Haible wrote:
>
> ...
> 3) There is the question whether getrandom() should be based on module
> crypto/gc-random. That is, whether the configure script should accept an
> option --with-libgcrypt, in order to use libgcrypt when available.
> I think the answer
> 1) The list of random devices, determined through gc-random.m4.
>
> > To fix that, I
> > am thinking that getrandom should remove its dependency on
> > crypto/gc-random, and
> > should simply use "/dev/urandom" for the nonce device without worrying about
> > whether crypto/gc-random would defin
Paul Eggert wrote:
> The remaining issue is "partial overlap with crypto/gc-random".
Yes. It has three aspects:
1) The list of random devices, determined through gc-random.m4.
> To fix that, I
> am thinking that getrandom should remove its dependency on crypto/gc-random,
> and
> should simply u
12 matches
Mail list logo
