[Gnuk-users] TRNG output
NdK
ndk.clanbo at gmail.com
Thu Sep 3 17:46:32 UTC 2015
Il 03/09/2015 19:22, Kurt Roeckx ha scritto:
>> Another interesting method I found some years ago (can't remember the
>> paper reference, sorry) is to consider couples of lsb readings. If the
>> two bits are equal, discard both. If they're different, discard the
>> first and store the second.
> This is known as von Neumann whitening, and you will actually find
> this in many papers. This is to remove the bias, and it
> properly does a good job with that, but I would prefer a
> cryptograhic hash for that instead since if you know the amount of
> entropy you put into it you might also be able to calculate the
> amount of entropy you get out of it.
Well, since the hash is deterministic, it does not add any entropy to
the stream, it just makes it harder to predict the outcome of an attack,
but it makes it harder to assess the quality of the generated stream.
> I've been wondering if all this is very important, and I guess the
> answer is going to depend on what you use the TRNG for. If you're
> just going to feed it to the kernel as an entropy source the raw
> samples might be more than enough, as long as you have a decent
> estimation of the amount of entropy you give the kernel. You
> would really like to feed the kernel around 256 bit of entropy
> before it starts generating output, so you want to make sure that
> that estimation is at least somewhat correct. After that adding
> more to the kernel isn't that important anymore, but you would
> still like to feed it some data.
Since the bandwidth is limited, it's better to pre-accumulate the
entropy, so you have to transmit less data for the same entropy.
> But at least rng-tools runs it's own fips test that of course fail
> on the raw data, even if you told it contains very few entropy per
> bit.
What does it say on a stream that uses just whitening on the lsb?
BYtE,
Diego
More information about the gnuk-users
mailing list