On Mon, Jan 27, 2025 at 05:02:36PM +0100, Markus Theil wrote: > As already mentioned in the comments, using a cryptographic > hash function, like SHA3-256, decreases the expected entropy > due to properties of random mappings (collisions and unused values). > > When mapping 256 bit of entropy to 256 output bits, this results > in roughly 6 bit entropy loss (depending on the estimate formula > for mapping 256 bit to 256 bit via a random mapping): > > NIST approximation (count all input bits as input): 255.0 > NIST approximation (count only entropy bits as input): 251.69 Bit > BSI approximation (count only entropy bits as input): 250.11 Bit > > Therefore add a cmdline override for the 64 bit oversampling safety margin, > This results in an expected entropy of nearly 256 bit also after hashing, > when desired. > > Only enable this, when you are aware of the increased runtime per > iteration. > > This override is only possible, when not in FIPS mode (as FIPS mandates > this to be true for a full entropy claim). > > Signed-off-by: Markus Theil <theil.markus@xxxxxxxxx> > --- > crypto/jitterentropy.c | 33 +++++++++++++++++++++++++++------ > 1 file changed, 27 insertions(+), 6 deletions(-) Why does this need to be a toggle? Why can't you just make this conditional on fips_enabled? Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
