En criptografía, la entropía describe la incertidumbre que le queda a un atacante al intentar adivinar un valor secreto. En una cartera Bitcoin importa desde que se crea la base de sus claves. La cuestión no es si los caracteres parecen complicados, sino cuántos resultados eran realmente posibles, qué probabilidad tenía cada uno y qué sabe el atacante del proceso.
Imagina que alguien crea un secreto a partir de la fecha y la hora de creación de una cartera. Al codificarlo puede parecer una larga mezcla de caracteres. Pero si el atacante conoce la hora aproximada y el método, quizá solo tenga que probar un pequeño conjunto de posibilidades. Una representación más larga no necesariamente le dificulta el trabajo. Por eso RFC 4086 distingue la imprevisibilidad de la mera apariencia de aleatoriedad. No puedes evaluar la entropía mirando una sola clave: necesitas saber cómo se creó. [3]
Un bit es una unidad básica de datos que vale 0 o 1. El número de bits, por sí solo, no indica cuánta incertidumbre le queda al atacante. Cuando una cartera crea una Seed Phrase según BIP39, primero necesita una entrada aleatoria. Solo después la convierte en palabras. Una frase de 12 palabras codifica 128 bits de entrada y 4 bits de suma de comprobación; una de 24 palabras, 256 bits de entrada y 8 bits de comprobación. La suma ayuda a detectar ciertos errores de transcripción, pero no añade entropía: se calcula a partir de la entrada existente. Una lista más larga tampoco arregla una aleatoriedad mal generada. Importa cómo se creó la copia de seguridad, no solo cuántas palabras tiene. [4]
Una cartera no necesita realizar una nueva medición física por cada byte, un grupo de 8 bits. Puede usar un generador criptográfico llamado DRBG: un algoritmo que produce más valores a partir de un estado inicial secreto. Si está bien diseñado y se usa correctamente, resulta difícil predecir las salidas sin conocer ese estado. Sin embargo, el algoritmo es determinista: el mismo estado completo y las mismas entradas producen la misma continuación. Generar más bytes no crea automáticamente más entropía física nueva. Importan tanto la entrada inicial como la protección del estado interno. [2]
Una función hash calcula a partir de los datos una huella de longitud fija que puede parecer aleatoria. Pero quien conoce la entrada puede calcular el mismo resultado. Así no se convierten en secreto unas entradas completamente conocidas. El término técnico conditioning describe un tratamiento que puede reducir el sesgo y concentrar la incertidumbre ya disponible. No crea un secreto de la nada. Tampoco se puede sumar automáticamente la entropía de varias fuentes: pueden estar relacionadas y aportar la misma información. [1] [3]
Una fuente de ruido electrónico puede averiarse o cambiar de comportamiento con las condiciones del entorno. Por eso NIST SP 800-90B exige comprobaciones del ruido sin procesar al arrancar y durante el funcionamiento, antes de su tratamiento. Buscan señales de fallo; no prueban que cada salida sea segura. El desarrollador debe conocer la fuente, sus límites y sus posibles dependencias. Un fallo detectado debe comunicarse a la aplicación que usa los datos. Si la avería es persistente, la fuente debe dejar de producir salidas. No basta por sí solo un chip etiquetado como generador aleatorio. [1]
Si un atacante obtiene el estado interno de un DRBG, puede predecir las salidas siguientes, según su diseño. Para recuperar la imprevisibilidad se necesita suficiente entrada nueva que el atacante desconozca; añadir esa entropía se llama reseeding. Seguir calculando o añadir una hora conocida no garantiza esa protección. También hay que distinguir entre reparar el generador y proteger los fondos existentes: recuperar el generador no invalida una clave que ya se ha filtrado. [2]
Un test estadístico puede detectar, por ejemplo, repeticiones sospechosas. Pero no puede determinar con certeza si el atacante conoce la entrada secreta o un método para predecir la salida. NIST SP 800-22 señala expresamente este límite. Los tests son una parte útil de la evaluación, no un sustituto del análisis del generador completo. Por tanto, un archivo lleno de números aparentemente aleatorios no demuestra por sí solo que una cartera sea segura. [5]
Un principiante no necesita calcular a mano la entropía de su cartera. Resulta más útil buscar un proceso documentado: de dónde obtiene la aleatoriedad, cómo la procesa, cómo responde a los fallos y cómo protege los secretos. NIST SP 800-90C trata precisamente de combinar fuentes de entropía y un DRBG en un generador completo. Pero citar una norma o un chip conocido no demuestra que una versión concreta de la cartera lo use bien. Lo que cuenta son las propiedades comprobadas de la implementación real. [1] [6]
Para obtener la imagen más completa, lee esta entrada junto con Entropy Bit, CSPRNG, Dice Roll Entropy, Private Key. También enlazan con esta entrada BIP85, Dice Roll Entropy, Entropy Bit, Brute Force Search Space.