anelok: entropy assist
werner at almesberger.net
Mon Oct 21 20:35:04 EDT 2013
> However, the more I think about it, the more I feel like that
> reaction is overblown and those concerns may not be entirely valid,
I have to admit that it's not quite intuitive :-)
> My immediate gut reaction is that this feels like a very high-risk
> thing to do, as you not only have to trust the system that generated
> it, but also risk having things revealed retroactively if this file
> is ever stolen and its encryption broken.
Yes, this needs examining. The file would be encrypted with a random
key that in turn is encrypted with the device's public key. (*) So
breaking the encryption of the entropy assist file would mean that one
has to do one of these (in addition to obtaining the file):
1) break the random key used for this file,
2) break the public key algorithm, or
3) break the device's private key.
2) is assumed to be infeasible. 1) should in general be rather
difficult except if the entropy of the random bits in the file or in
its key (let's assume they come from the same source) is very low.
This would in turn mean that the whole entropy assist pool is weak,
which means it shouldn't be used as a standalone source in the first
That leaves 3). The impact of that would depend on how that key is
used. Most likely, it would expose all the password database entries
the device is allowed to read to fairly easy brute force attacks
since they'd then be only protected by the user's unlock code ("PIN").
In this case, the entropy assist pool may no longer be of much
interest. But yes, this needs closer examination once the whole
architecture takes shape.
(*) This is roughly how I imagine we'll do things. May change.
> I do wonder about the feasibility of extracting some random bits
> from the timing of the input wheel,
Yes, there should be a few bits of entropy in each wheel action.
It's a very low-bandwidth randomness source and further weakened
by sleep states, critical sections, and such. It's probably too
slow for use as a standalone source, but it may be useful for
mixing up the randomness pool further.
To properly assess its quality, one would have to make a "live"
system record SysTick timestamps on wheel interrupts and then
analyze their statistical distribution. Chances are there's a
nice bell curve around T/48 where T is the time it takes the user
to spin the wheel one full circle (the wheel has 24 stops and
generates two signal changes when moving from one stop to the
More information about the discussion