Page MenuHome GnuPG

jitter entropy RNG update
Closed, ResolvedPublic

Description

http://www.chronox.de/jent.html has new version.

It will be good for libgcrypt to import new version.

Event Timeline

werner added a project: FIPS.

For Linux and FIPS, we should be actually fine with using /dev/random or getrandom().

I also noticed the file random/random-fips.c, which looks like some outdated version of fips random number, which was not updated for ages. Would it make sense to remove it? I think it is not used anywhere.

We should update jitterentropy to 3.0.2 or newer, which should be easier to get through certification, if we will go this way. From FIPS perspective, we should be fine with either going through getrandom only or with jitter entropy, but the bottom-line was that we should probably keep both as we do now.

We do it with the following patch:

https://src.fedoraproject.org/rpms/libgcrypt/blob/rawhide/f/libgcrypt-1.8.5-getrandom.patch

I see this patch has already some history, but the latest bug I was able to find related to this patch was https://bugzilla.redhat.com/show_bug.cgi?id=1380866 which handles the libgcrypt preventing boot of the system. It will probably require some clarifications, so please ask.

werner moved this task from Backlog to Next on the FIPS board.

I work on gniibe/jitterent branch.
I realized that full featured jitterentropy now requires pthread. Timer-less mode uses threads for entropy. This is not good for libgcrypt use.

Its copyright notice in upstream now refers LICENSE file, which requires some arrangement.

If I read it right, the version 3.1.0 adds the pthread requirement. Using 3.0.2 should be fine for us.

I decided to use 3.3.0 disabling pthread feature.

I tried to use internal SHA-3 implementation of libgcrypt, but it looks like it's better to keep using jitterentropy-sha3.c, for the sake of "less surprise".

In 2.1.0, it was LFSR. In 3.3.0, it uses SHA-3.

Pushed to master.

It found that newer jitterentropy uses larger mem (128KiB), while older uses 2KiB.

This means that, it doesn't work well with secure memory, as its standard size is 32KiB.

Currently, _gcry_rndjent_poll always fails, because of no allocation of secmem.

->mem is just used to measure the difference of memory access.

So, I think that it's totally no problem to use normal memory instead of secure mem.

Fixed, with using normal memory for ->mem.

I went through some more testing and noticed one missing file in the release tarball, that prevents building libgcrypt now. Should be fixed with the attached patch.

gniibe removed a project: Restricted Project.