Revisions and Commits
|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.|
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:
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.
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.
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.