[Gnuk-users] TRNG output

[Kurt Roeckx]

On Thu, Sep 03, 2015 at 02:15:40PM +0200, NdK wrote:
> Il 29/08/2015 23:25, Kurt Roeckx ha scritto:
> 
> > An other very interesting paper is this one:
> > https://eprint.iacr.org/2011/659
> 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.

> The drawback is that the rate of the random bitstream depends on the
> instability of the source: if the source is stuck (say an attacker
> pulled the analog line under gnd, say -.3V : the ADC would consistently
> give all zeroes -> no bitflips -> no random bits generated).

You will always need to have a way to try and detect that it's not
working properly anymore.


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.

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.


Kurt