Qué pasó
Entre el 17 y el 19 de agosto de 2026, Coinkite subió al repositorio del firmware de Coldcard un conjunto de cambios que reescriben cómo el dispositivo produce la aleatoriedad detrás de una seed nueva. Están listados en el changelog sin publicar del repositorio, bajo las versiones 5.6.1 (Mk4, Mk5) y 1.5.1Q (Q), ambas fechadas el 20 de agosto de 2026. Vienen después del parche urgente del 31 de julio, que avisó a los propietarios que las seeds generadas con firmware anterior tenían una entropía "críticamente baja": unos 40 bits en Mk3, y hasta apenas unos 72 bits en Mk4, Mk5 y Q, frente a un objetivo declarado de 128. A quienes tenían una Mk3 se les indicó mover los fondos a seeds nuevas.
Qué cambia
Un hardware wallet que genera una seed cumple una sola tarea que importa: producir un número que nadie pueda adivinar. El nuevo changelog trata esa tarea como algo que hay que demostrar, no suponer.
La generación de la seed maestra ahora mezcla entropía fresca de tres fuentes - el generador de
hardware del STM32 y los dos secure elements - en lugar de apoyarse en esos elementos solo a
través del sembrado durante el arranque, que a su vez ahora usa el digest completo de 256 bits
y no un truncamiento a 32 bits. El generador por software de la biblioteca criptográfica de
Coinkite pasó del algoritmo Yasmarang a un Hash_DRBG con SHA-256 del NIST SP 800-90A, y las
contraseñas de backup, la sal de cifrado y los secretos de 2FA
se movieron a él.
Dos agregados hablan directamente de cómo el defecto de julio sobrevivió cinco años. Una
autoprueba en el arranque "demuestra que rng_get() entra en el camino de lectura del
hardware" y detiene el arranque si no lo hace, y una comprobación en tiempo de compilación
verifica que el camino de bytes aleatorios de la biblioteca llegue siquiera a la implementación
de hardware. Un generador de números aleatorios que falló en silencio produce una salida
idéntica a la de uno que funciona, y por eso el arreglo es una prueba y no una corrección.
Las seeds nuevas además exigen ahora entropía aportada por la persona - dados físicos, tiradas
de moneda o tecleo cronometrado - sumada a las fuentes de hardware, no en reemplazo de ellas.
Qué no cambia
El firmware nuevo no repara una seed vieja. La entropía queda fijada en el momento en que se generan las palabras, así que una seed débil sigue siendo débil en cualquier versión. Quien tenga un dispositivo afectado enfrenta igual una migración: generar una seed nueva con firmware corregido, respaldarla, probar la restauración, mover las monedas en cadena y actualizar cualquier registro de herencia que apunte al respaldo anterior. Eso es todo el self-custody hecho dos veces, contra reloj, y tiene sus propias formas bien documentadas de salir mal.
Las comprobaciones, además, demuestran un camino, no una calidad. Confirmar que el código llega a un registro de hardware no dice nada sobre si los números que salen de ese registro son buenos. Y quien se ponga a tirar dados confía en que el firmware los mezcle como dice el texto: la cobertura vale lo que valga ese código de mezcla, y desde la pantalla del propio dispositivo no hay forma de verificarlo.
Contexto
El parche del 31 de julio frenó la hemorragia: arregló la generación hacia adelante y avisó que había que mover los fondos. Lo que está en cola ahora es la versión estructural de esa misma respuesta, y llega junto a una larga lista de endurecimientos sin relación en el mismo changelog, buena parte acreditada a investigadores externos, incluido un caso en el que un host USB comprometido podía reescribir una transacción ya preparada después de que la persona la revisara y antes de que el dispositivo la firmara.