whitening of user generated entropy
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- cpp
- Ambito
- cryptography, embedded-iot
Direzione di ricerca
Non vengono indicati file, test o punti di ingresso. Confronta gli approcci proposti di raw-binary input ed entropy-whitening, quindi definisci un criterio di accettazione verificabile per bit uniformi e determina se la funzionalità debba includere un approccio o entrambi.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- C++
- Stelle
- 58
- Fork
- 12
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di BlockchainCommons/lethekit
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
BlockchainCommons/lethekit#61 · 7 commenti ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
-
new libraries requiredAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
BlockchainCommons/lethekit#40 · 12 commenti ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
BlockchainCommons/lethekit#38 · 13 commenti ·
Tutte le issue di BlockchainCommons/lethekit
Issue simili
-
code-quality libc++
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
llvm/llvm-project#229284 ·
I maintainer di solito rispondono entro 1 giorno
-
test-issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
llvm/offload-test-suite#1557 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
iOS: hidden scale bar invalidates its intrinsic content size on every layout pass of MLNMapViewAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
maplibre/maplibre-native#4723 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
HarbourMasters/Shipwright#7320 ·
I maintainer di solito rispondono entro 1 giorno