#dusk $DUSK @Dusk
Volví a revisar las notas de seguridad del monedero de Dusk y el changelog de la v0.3.0 con una suposición sencilla: la seguridad del monedero consistía en proteger la frase semilla y establecer una contraseña sólida.
El diseño de la extensión es más operativo. Su mnemónico está cifrado en reposo con PBKDF2 y AES-GCM-256, pero un mnemónico desbloqueado aún permanece en la memoria de JavaScript y no se puede garantizar que se borre de forma segura (zeroized). El auto-bloqueo se activa mediante alarmas del navegador; la v0.3.0 corrigió la marca de tiempo de actividad que sobrevivía a reinicios de background workers y preservó eventos de estado bloqueado para dApps conectadas. El proveedor también comprueba la longitud del memo y rechaza los memos en llamadas a contratos porque la carga útil puede ser un memo o una llamada, no ambas. Los registros antiguos de bóvedas no compatibles se eliminan y requieren volver a importar el mnemónico en lugar de aceptarse silenciosamente.
Eso hizo que lo mirara de otra manera.
Mi interpretación: la privacidad puede fallar en el límite entre la sesión y el estado local incluso cuando la criptografía de transacciones protegidas (shielded) es sólida.
Mi incertidumbre es el equilibrio entre recuperación. ¿Rechazar un formato antiguo de bóveda protege a los usuarios de registros manipulados o débiles, o crea un nuevo riesgo operativo cuando un usuario no puede encontrar la semilla? ¿Y los auto-bloqueos frecuentes fortalecerán el uso real o entrenarán a las personas para aprobar indicaciones sin leer?
Quiero verlo en la práctica.
Volví a revisar las notas de seguridad del monedero de Dusk y el changelog de la v0.3.0 con una suposición sencilla: la seguridad del monedero consistía en proteger la frase semilla y establecer una contraseña sólida.
El diseño de la extensión es más operativo. Su mnemónico está cifrado en reposo con PBKDF2 y AES-GCM-256, pero un mnemónico desbloqueado aún permanece en la memoria de JavaScript y no se puede garantizar que se borre de forma segura (zeroized). El auto-bloqueo se activa mediante alarmas del navegador; la v0.3.0 corrigió la marca de tiempo de actividad que sobrevivía a reinicios de background workers y preservó eventos de estado bloqueado para dApps conectadas. El proveedor también comprueba la longitud del memo y rechaza los memos en llamadas a contratos porque la carga útil puede ser un memo o una llamada, no ambas. Los registros antiguos de bóvedas no compatibles se eliminan y requieren volver a importar el mnemónico en lugar de aceptarse silenciosamente.
Eso hizo que lo mirara de otra manera.
Mi interpretación: la privacidad puede fallar en el límite entre la sesión y el estado local incluso cuando la criptografía de transacciones protegidas (shielded) es sólida.
Mi incertidumbre es el equilibrio entre recuperación. ¿Rechazar un formato antiguo de bóveda protege a los usuarios de registros manipulados o débiles, o crea un nuevo riesgo operativo cuando un usuario no puede encontrar la semilla? ¿Y los auto-bloqueos frecuentes fortalecerán el uso real o entrenarán a las personas para aprobar indicaciones sin leer?
Quiero verlo en la práctica.
