Siempre que esté utilizando correctamente un modo de cifrado autenticado aprobado por el NIST (como AES-CBC & HMAC-SHA con los KDF y IVs adecuados, e.t.c.), romper esto debería ser tan difícil como simplemente romper un archivo cifrado. Ahora, dependiendo de su caso de uso, esto podría / no podría ser suficiente. Lo llevaré a través de un par de otras opciones que puedo pensar, así como los posibles beneficios / inconvenientes de seguridad que puede ofrecer.
Opción 1: cifrado autenticado estándar con clave privada cifrada almacenada en la base de datos
Esto (como se mencionó anteriormente) será, por lo que respecta a la seguridad, tan bueno como cifrar un archivo de la misma manera, y debería ser tan difícil de romper como el cifrado subyacente. Sin embargo, ofrece un gran inconveniente: esto permite que un atacante destruya / modifique irreversiblemente los datos de la clave privada, porque esto simplemente no forma parte del modelo de amenaza de cifrado (solo se preocupa de que los datos sean secretos y no puedan modificarse sin ser detectados) . Aquí es donde propongo la solución no.2:
Opción 2: DERIVAR la clave privada con la contraseña del usuario
Esta opción implica (básicamente) alimentar su clave derivada a un PRNG y generar la clave privada cada vez (siempre que necesite la clave privada, solo la derive de la contraseña del usuario), esto tiene la ventaja de
- ni siquiera se almacena en la base de datos,
- la clave privada (obviamente) no se puede corromper ahora, porque no está almacenada en ninguna parte.
Sin embargo, esta opción puede ser un poco más arriesgada que la opción 1 debido a dos razones:
- Los PRNG generalmente se consideran inferiores en términos de seguridad para bloquear cifrados (como AES)
- Dependiendo de su elección, un ataque de fuerza bruta en la contraseña subyacente PUEDE ser más rápido que intentar romper AES
- El número de claves privadas posibles es ahora inevitablemente mucho más corto (debido a la naturaleza de un generador de números aleatorios).