[Announce] Libgcrypt 1.8.4 released

[Daniel Kahn Gillmor]

On Tue 2018-10-30 15:33:03 +0100, Werner Koch wrote:
> On Mon, 29 Oct 2018 18:22, dkg at fifthhorseman.net said:
>
>> This characterization is unfortunate, since the getrandom() default
>> behavior is *not* the /dev/urandom behavior.  In particular, the
>
> I used to explain that getrandom uses the urandom pool and not the
> random pool.  They are separate and have different properties.  See
> Stephan Müller's paper he wrote for the BSI.

right, but the release notes say it uses the /dev/urandom *behavior*,
not the urandom *pool*.  the /dev/urandom behavior is still:

 a) whether the urandom pool is initialized or not, use it.

but what getrandom() does is:

 b) wait for the urandom pool to be initialized, and then use it.

>> getrandom() default behavior blocks until the kernel's internal pool has
>> been fully initialized, while /dev/urandom never blocks.  This is one of
>
> That is detail and could even be viewed as a bug fix for the
> open("/dev/urandom") behaviour.  Which in the early days of Linux was
> also different.

that is certainly detail, but it is the relevant detail here :)

> Those who are using Libgcrypt in the early boot phase should be aware of
> the problem with modern Linux kernels.    Again, see the paper.

I'm assuming that "the early boot phase" means "until the crng is
initialized".  On minimalist virtual machines that use a modern system
supervisor that has relatively short boot times, it can be a
surprisingly long time after system boot that the crng is initialized.
I suspect that there are users of libgcrypt who don't know that their
code is being run in this sense of "in the early boot phase".

At any rate, the change in gcrypt 1.8.4 actually *helps* those users,
rather than harms them, because it removes unnecessary blocking while
avoiding exposing the user to use of an unintialized RNG.  so as long as
they're running a modern kernel, they don't need to read the paper :)

thanks for making the change!

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20181030/540bdfac/attachment.sig>