http://www.chronox.de/jent.html has new version.
It will be good for libgcrypt to import new version.
Description
Description
Revisions and Commits
Revisions and Commits
| rC libgcrypt | |||
| rC78ce1f9e0afe random: Add missing header file to the release tarball | |||
| rCa44301f6d205 jitterentropy: use wipememory for jent_memset_secure | |||
| rCc38ebc3b6c7d jitterentropy: fix building on Win32 | |||
| rC1183ffdd7a24 tests: Remove tweak for FIPS enabled. | |||
| rC85cb7375fec3 jitternetropy: Put our local change to use non-secure memory. | |||
| rC2101da04924b jitterentropy: Use jent_read_entropy_safe for rndjent. | |||
| rCd0fcb4da98a0 Fix jent_read_entropy for JENT_CPU_JITTERENTROPY_SECURE_MEMORY. | |||
| rCd5ae5229db70 jitterentropy: Fix building rndjent. | |||
| rC964c9c5eee30 jitterentropy: Disable use of pthread. | |||
| rC3bacdac611b9 jitterentropy: Merge from jitterentropy-library-3.3.0. | |||
| rCcf85258e6aff jitterentropy: Fix for C90 compiler. | |||
Related Objects
Related Objects
- Mentioned In
- T5691: Release libgcrypt 1.10.0
- Mentioned Here
- rCed57fed6de14: random: Add SP800-90A DRBG
Event Timeline
Comment Actions
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.
Comment Actions
I think the last user of random-fips was removed with rCed57fed6de1465e02ec5e3bc0affeabdd35e2eb7
Comment Actions
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.
Comment Actions
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.
Comment Actions
Its copyright notice in upstream now refers LICENSE file, which requires some arrangement.
Comment Actions
If I read it right, the version 3.1.0 adds the pthread requirement. Using 3.0.2 should be fine for us.
Comment Actions
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.
Comment Actions
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.
Comment Actions
->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.
Comment Actions
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.