¿Por qué se usa HMAC-SHA512 en root the root seed para crear una clave privada maestra y un código de cadena en billeteras HD?

El proceso se representa en esta imagen. Específicamente, dado que la semilla raíz se derivó usando PBKDF2 (con 2048 rondas de hash con HMAC-SHA256 ya), ¿por qué pasamos por un pase adicional de HMAC-SHA512, además de crear 512 bits de entropía? ¿Por qué no usar solo SHA512? He preguntado aquí antes y la respuesta que obtuve fue que la versión HMAC se usa para garantizar la generación única de la clave, pero no sé qué significa eso. Parece que para la derivación de la clave privada maestra y el nodo de la cadena, la función se usa solo como una función hash unidireccional, entonces, ¿por qué se usa un MAC? Se está cifrando una sola cosa, tampoco estamos tratando de garantizar la autenticidad de nada aquí, ¿verdad?

Respuestas (3)

Específicamente, dado que la semilla raíz se derivó usando PBKDF2 (con 2048 rondas de hash con HMAC-SHA256 ya), ¿por qué nos sometemos a

y

¿un pase adicional de HMAC-SHA512, además de crear 512 bits de entropía?

Esas cosas vienen de diferentes estándares. BIP32 (que especifica pasar de la llave maestra a las llaves) fue lo primero. Se están utilizando varias formas de construir claves maestras/semillas que llegaron más tarde; Supongo que te refieres a uno de esos.

¿Por qué no usar solo SHA512?

No estoy seguro. Creo que eso funcionaría bien. El único detalle complicado sería que también debe incluir la frase de contraseña.

Parece que para la derivación de la clave privada maestra y el nodo de cadena, la función se usa solo como una función hash unidireccional,

Para ser completamente preciso, necesita más que una función unidireccional. Por ejemplo, si la función hash siempre produjera un hash que fuera divisible por 3, seguiría todas las propiedades de la función hash, pero sería más débil como función de derivación de clave.

Estoy dispuesto a apostar que las 2048 rondas de hashing requeridas por el estándar BIP 39 consumen mucha más energía que 1 ronda de hashing.

Dicho de otra manera, se requieren ciclos de computación sustanciales para crear tablas Rainbow de fuerza bruta cuando las semillas legibles por humanos de baja entropía se asignan funcionalmente a claves privadas. Esto es algo análogo a los valores de ceros de hash principales que los mineros satisfacen para agregar bloques a una cadena de bloques basada en PoW, excepto que los ciclos de computación están fijados por la porción de mnemónicos a semilla del estándar BIP39.

El tramo de Python puede implementar efectivamente la funcionalidad de mnemónicos a semilla escrita en BIP 39.

stretch->passlib.pbkdf2(secret, “mnemonic”+salt, rounds=2048, keylength=64, sha512)

Los dos ejemplos relacionados con Bitcoin de comandos canalizados que usan stretch y bx arrojan el mismo resultado.

% stretch -f sha512 -r 2048 "naufragio búnker borde real infligir aeróbico amigo misericordia divorcio lobo brillante inmune grasa pie poeta sección sostener revelar único reflexionar tener latino problema capítulo" mnemónico123 | bx base64-decodificación | bx base16-encode | bx hd-nuevo | bx hd-privado xprv9veSXAfA7GoYvaMAXgm3uYGS4VLH1Foc9qmTBRCb4c3F2Vqd261k2vo646nLU54MRVseFx2BbhZYQS9HDUy4dvTV3fygVGxedqYSR82B3he

% echo "bunker naufragio borde real infligir aeróbico amigo misericordia divorcio lobo brillante inmune gordo pie poeta sección sostener revelar único reflexionar tener latino problema capítulo" | bx mnemotécnico-a-semilla -p 123 | bx hd-nuevo -v 76066276 | bx hd-privado xprv9veSXAfA7GoYvaMAXgm3uYGS4VLH1Foc9qmTBRCb4c3F2Vqd261k2vo646nLU54MRVseFx2BbhZYQS9HDUy4dvTV3fygVGxedqYSR82B3he

Esto no responde a la pregunta de por qué se usa HMAC-SHA-512 en lugar de SHA-512.
Las tablas Rainbow no son aplicables a BIP39; el espacio clave es demasiado grande para construirlos.
% echo -n "Mierda" | bx base16-encode | bx sha256 | bx mnemónico-nuevoshiver enact raise shoe vocal evidence dismiss lawsuit hospital multiply project wonder art fish next club bridge steak ritual face recipe school knife second