Criptografía asimétrica como función de hash

TL;DR

1. La desventaja que mencionas es menos relevante de lo que crees.

2. La mayor desventaja del cifrado asimétrico es que es bastante más barato que un Hash de contraseña lenta configurado correctamente.

Por lo tanto, debes usar un hash de contraseña lento. (es decir, BCrypt)

Teóricamente, el uso de una rutina de cifrado asimétrico (donde la clave privada se olvida permanentemente) es una función hash unidireccional bastante segura, pero no es adecuada para datos de entrada de baja entropía (es decir, contraseñas)

  

La criptografía asimétrica suele ser más costosa que el hash y, por lo tanto, debería requerir menos estiramiento por los mismos beneficios.

Veo que entiendes la importancia de una costosa rutina de hash para prevenir la Fuerza Bruta. Si bien el cifrado asimétrico es más lento que las funciones de hash de propósito general (es decir, SHA-2), lo que debería usar es una función de slow hash (es decir, BCrypt), que es más caro que cualquiera de las dos opciones mencionadas anteriormente.

  

Mayor garantía en la contraseña ingresada: solo hay una contraseña que puede ser aceptada. Es decir, ninguna colisión puede ser   Aceptado (a diferencia de las funciones hash) como si no, el descifrado   la contraseña no sería única.

Las funciones hash modernas tienen un espacio de nombres lo suficientemente grande como para que no ocurra una colisión durante la vida útil de la aplicación. Tratar de encontrar algo aún más resistente a las colisiones no tiene sentido.

  

La principal desventaja que veo es que la longitud de la contraseña almacenada es   correlacionada con la longitud real de la contraseña, dando una pista sobre la contraseña   fuerza. Esto puede mitigarse introduciendo una sal "larga" en el   contraseña, lo que garantizará que la contraseña corta solo se vea tan corta como   la sal. La contraseña larga no se ve afectada, pero está bien, ya que   son largos pero pueden ocupar espacio en la base de datos.

El atacante podría ver cuántos bloques de largo puede tener la contraseña cifrada, pero no podrían decirlo más específicamente que eso. La gran mayoría de las contraseñas se pueden almacenar en un solo bloque (asumiendo un tamaño de clave fuerte como RSA 1024 o RSA 2048), por lo que esta pista sería de uso limitado para un atacante.

  

¿Existen otras desventajas en esta técnica?

1. La criptografía asimétrica es menos costosa que una rutina de Slow Password Hash como BCrypt.

2. Los requisitos de espacio en disco son más altos.

3. "No hagas tu propio rollo".

Ahí lo tienes, deberías usar un hash de contraseña lenta, como

• BCrypt, pero asegúrese de ejecutar un hash SHA-2 rápido en los datos de entrada, de manera que BCrypt no truncará las contraseñas súper largas
• PBKDF2 pero eso es menos resistente a GPU
• SCrypt es mejor que BCrypt si tiene un factor de trabajo suficientemente alto. De lo contrario, es peor contra las GPU.
• El ganador de la Competición de hash de contraseñas puede ser incluso mejor que el mencionado anteriormente, pero aún no ha superado la prueba del tiempo, por lo que No lo uses todavía. Se llama Argon2 y tiene configuraciones de Factor de trabajo separadas para el tiempo de CPU y la carga de memoria. (bonito!)

La mayoría de estas opciones generan sal aleatoria de forma predeterminada, ¡pero verifica si este es el caso!

Es mejor incluir un poco de Pepper (~ 72 bits de entropía) antes de la Contraseña antes del hash. Pepper puede ser el mismo para todos sus usuarios, pero debe almacenarse en un archivo fuera de la base de datos para que no se pueda encontrar ese componente a través de Inyección SQL.

Asegúrese de que su factor de trabajo requiera aproximadamente 100 ms (con la protección DoS adecuada) en su hardware de destino (sabiendo que los atacantes usarán un hardware más rápido para la fuerza bruta)

No puedo entender por qué crees que esto sería mejor que usar una de las funciones estándar de derivación de claves:

Su primer argumento no tiene sentido: durante el estiramiento, el tipo de trabajo que está haciendo solo es importante en el sentido de que desea que se diseñe para ser lento en todo tipo de hardware (que definitivamente NO es uno de los objetivos de diseño de una función de cifrado típica).

Su segundo argumento solo sería válido si está utilizando contraseñas sin sal con una función hash débil. De lo contrario, no sería resistente a la pre-imagen.