whitening of user generated entropy

[nothingmuch]

Two related feature ideas in one:

1. allow input to be interpreted as coin tosses/raw binary instead of dice rolls
2. entropy whitening of inputs. total rolls/tosses required may be higher, but ensure some number of unformly random bits were obtained, compensating for any bias in the dice.

There are two approaches of doing (2) that differ in how easy they are to audit:

• Allow a larger buffer to hash before trng entropy, but require for at least MIN_DICE_ENTROPY (new constant, e.g. 128) uniform bits can be extracted from it. If MIN_DICE_ENTROPY is not reached, the rolls could be rejected and another attempt made, so MAX_DICE_ENTROPY should probably be raised to ~384, so that after appending 128 bits of trng output would still fit in a single sha256 block. Requires more rolls to be copied when auditing.

• Hash only hash whitened bits, up to MAX_DICE_ENTROPY, requires decoding to audit. the only way i can think of auditing by hand with dice rolls is converting from base 6 to binary and using von Neumann whitening which is laborious, but becomes very easy with binary input, hence the motivation for binary input.

Alternatively (2) can be omitted entirely, since just some form of binary input would suffice: since the user can do von Neumann whitening on their coin tosses easily before inputting anything into the device which would guarantee uniformity with no additional code.

[gorazdko]

allow input to be interpreted as coin tosses/raw binary instead of dice rolls

this one is definitely viable and an easy option to add. We already support it in our "desktop" version of seedtool (bc-seedtool-cli)

I'll try to get some feedback about the second idea.