Recuperar una cuenta, una identidad y un historial de conversaciones son operaciones distintas; comprueba cuál admite realmente el producto.
La recuperación de identidad criptográfica restaura el material de claves asociado a tu identidad de mensajería. No equivale automáticamente a volver a iniciar sesión en una cuenta, restaurar todas las conversaciones ni demostrar que un dispositivo de sustitución es seguro.
Una copia de seguridad cifrada de claves puede permitir que un servidor almacene un paquete recuperable sin poseer el secreto necesario para abrirlo. Que ese diseño proteja al usuario depende de la generación de claves, la autenticación, la custodia del secreto de recuperación y cómo gestione el cliente la identidad recuperada.
Tres cosas que se llaman «recuperación»
| Objetivo de recuperación | Qué debe restaurarse o autorizarse |
|---|---|
| Acceso a la cuenta | Permiso para iniciar sesión y usar el servicio |
| Identidad criptográfica | Las claves privadas adecuadas o una nueva identidad autenticada |
| Historial de chat | Los datos de mensajes y las claves o el estado necesarios para leerlos |
Un inicio de sesión correcto no demuestra ninguno de los otros dos resultados. Del mismo modo, una clave de identidad no recrea necesariamente claves antiguas de mensajes que se borraron deliberadamente ni un archivo de historial que ya no existe.
Anota qué objetivo promete realmente la función de recuperación de un producto antes de confiar en ella.
Cómo puede funcionar una copia cifrada de identidad
Un diseño habitual genera material de identidad en un dispositivo de confianza, cifra una copia con un secreto de recuperación independiente y almacena en el servicio únicamente el paquete protegido. Un dispositivo de sustitución obtiene el paquete y utiliza el secreto de recuperación localmente.
El servidor puede seguir controlando el acceso al paquete, observando solicitudes, reteniendo datos o devolviendo una versión antigua. El cifrado autenticado y la vinculación con la versión y la identidad ayudan a afrontar riesgos concretos de manipulación; la disponibilidad y la gestión de reversiones necesitan su propio diseño. «Cifrado en el servidor» no responde por completo a todos los escenarios de compromiso del servidor.
Una clave de recuperación aleatoria de alta entropía y una contraseña elegida por una persona también son entradas diferentes. No describas HKDF como un método que convierte cualquier frase de contraseña débil en un secreto fuerte. RFC 5869 explica la función de HKDF y lo distingue del fortalecimiento de contraseñas mediante estiramiento.
Qué dice la documentación v7 de Livara
La página de seguridad de Livara dice que sus claves P-256 de acuerdo de claves y firma, junto con la semilla ML-KEM, se cifran en el dispositivo con una clave de recuperación aleatoria de 256 bits antes de subirlas. El formato v7 autentica información que incluye la suite, la época de identidad y la generación.
La misma página es explícita: restaura la identidad, no el historial de chat. También indica que una contraseña de acceso correcta por sí sola no basta para abrir la copia cifrada de claves; se necesita la clave de recuperación representada por la frase de recuperación.
Son afirmaciones publicadas sobre el producto, no una auditoría nueva del formato de copia ni de todas las vías de recuperación. El modelo de amenazas, más general, debe leerse junto con esta descripción más específica de la recuperación.
Qué papel desempeña SRP
El modelo de autenticación SRP se refiere al inicio de sesión basado en contraseña. Puede evitar transmitir la propia contraseña en el intercambio previsto por el protocolo, pero no define el contenido de una copia de claves ni deriva automáticamente todas las claves de recuperación.
Su verificador del lado del servidor sigue necesitando protección. RFC 5054, sección 3.3 describe el riesgo de adivinar contraseñas tras el robo de un verificador. No conviertas «el servidor no recibe la contraseña en este intercambio» en «una intrusión en el servidor no puede revelar nada útil».
Las sesiones de cuenta, los paquetes de recuperación, los metadatos operativos y el software cliente son activos distintos con modos de fallo distintos.
Lista para preparar una recuperación segura
- Confirma exactamente qué datos restaura la función y cuáles no.
- Guarda el secreto de recuperación donde perder el teléfono no implique también perder la única copia.
- Evita incluir el secreto en un mensaje, una solicitud de soporte o una captura de pantalla pública.
- Protege el lugar donde guardas el secreto; quien lo consiga puede adquirir capacidades importantes si también obtiene la copia correspondiente y el acceso necesario.
- Revisa las instrucciones oficiales de recuperación antes de borrar o sustituir el único dispositivo que funciona.
- Prueba solo mediante procedimientos admitidos, sin destruir la única copia de datos importantes.
Después de la recuperación, revisa por separado los dispositivos vinculados y las sesiones. Recuperar el material de identidad no revoca automáticamente un dispositivo antiguo. Si cambia la identidad criptográfica, los contactos con comunicaciones sensibles deben verificar la nueva clave por una vía de confianza independiente.
Si se pierde la frase de recuperación
No supongas que el soporte puede recrear un secreto que el sistema se diseñó para no conservar. Tampoco supongas que olvidar cualquier contraseña de cuenta significa que todos los mensajes locales ya han desaparecido. El resultado depende de los dispositivos que queden, las copias disponibles y las reglas documentadas del producto.
La pregunta útil es concreta: «¿Qué secreto o copia falta, y qué objetivo de recuperación sigue siendo posible?». Esto produce una respuesta más segura que prometer de forma general que recuperar es sencillo o imposible.
