whitening of user generated entropy
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- cpp
- Área
- cryptography, embedded-iot
Línea de trabajo
No se nombran archivos, pruebas ni puntos de entrada. Compara los enfoques propuestos de raw-binary input y entropy-whitening, luego define un criterio de aceptación auditable para bits uniformes y determina si la funcionalidad debería incluir uno de los enfoques o ambos.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- C++
- Estrellas
- 58
- Forks
- 12
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de BlockchainCommons/lethekit
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
BlockchainCommons/lethekit#61 · 7 comentarios ·
-
allow fixing invalid mnemonicAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 30/100
-
new libraries requiredAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
BlockchainCommons/lethekit#40 · 12 comentarios ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
BlockchainCommons/lethekit#38 · 13 comentarios ·
Todos los issues de BlockchainCommons/lethekit
Issues similares
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
iOS: hidden scale bar invalidates its intrinsic content size on every layout pass of MLNMapViewAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
maplibre/maplibre-native#4723 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
HarbourMasters/Shipwright#7320 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Make Catch2 optional when `RDK_BUILD_CPP_TESTS=OFF`Posiblemente ocupada @pechersky la tomó hoy. Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 2 días