whitening of user generated entropy
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- cpp
- Domain
- cryptography, embedded-iot
Research direction
No files, tests, or entry points are named. Compare the proposed raw-binary input and entropy-whitening approaches, then define an auditable acceptance criterion for uniform bits and determine whether the feature should include one approach or both.
Written by the indexing model from the issue text.
Description
Two related feature ideas in one:
- allow input to be interpreted as coin tosses/raw binary instead of dice rolls
- 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.
- Dominant language
- C++
- Stars
- 58
- Forks
- 12
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from BlockchainCommons/lethekit
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
BlockchainCommons/lethekit#61 · 7 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 30/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
BlockchainCommons/lethekit#40 · 12 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
BlockchainCommons/lethekit#38 · 13 comments ·
All issues in BlockchainCommons/lethekit
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
espressif/esp-matter#1874 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
opencv/opencv_contrib#4231 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
MiSTer-devel/Main_MiSTer#1341 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
linux-test-project/lcov#552 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 1-3 hours Newbie friendliness 94/100
Maintainers usually reply within 1 day