¿Hay cifrados diseñados para ser lentos?

La mayoría de los algoritmos de encriptación ya son relativamente lentos y juzgar el éxito también es mucho más difícil. Cuando intenta determinar la entrada para un hash, conoce la salida deseada. Sin embargo, cuando intenta descifrar el cifrado, generalmente no conoce el texto sin formato deseado, incluso si lo hace, el espacio potencial de entrada es generalmente mucho, mucho más grande.

Cada dígito de una contraseña solo vale unos 7 bits de entropía, incluso si se elige de forma aleatoria. Incluso el extremo inferior de una clave simétrica estándar generalmente utiliza 128 bits de entropía. La velocidad del hashing no importaría mucho si todos usaran contraseñas de 18 caracteres verdaderamente aleatorias. Además, el atacante generalmente desconoce el texto simple que necesita para acceder y los algoritmos de encriptación generalmente operan un poco más lento de todos modos, ya que tienen que realizar operaciones más complicadas en un conjunto más largo de datos.

Entonces, en cierto sentido, no, no hay algoritmos diseñados para ser específicamente lentos como objetivos de diseño, pero no tienen que serlo, ya que el nivel de seguridad proporcionado y la velocidad normal del algoritmo no lo hacen. hay que ser lento para ser práctico. Un ataque de fuerza bruta contra una clave bien elegida en un algoritmo de cifrado de 128 bits sin vulnerabilidades sistemáticas ya llevaría más tiempo de lo que quemaría nuestro sol, por no decir nada de las claves de 256 bits (lo que no se haría en el hardware actual antes de la muerte térmica) del universo). Ir más lento simplemente no es necesario.

Si tuviera que utilizar una función de derivación de clave para una clave derivada de contraseña, debería ser lenta, pero no querría hacer que el descifrado en sí sea lento, ya que sería ineficiente.

En cuanto al almacenamiento de claves privadas SSH, dependería completamente de la implementación de la función de derivación de claves, no de la velocidad del algoritmo de cifrado, pero sugeriría probablemente al menos 10 caracteres si quiere que resistan fuertemente el forzado brutal incluso para una derivación de clave razonablemente lenta (no estoy seguro de qué utiliza el almacenamiento de claves privadas SSH, y puede variar según el cliente).

En su mayor parte, no. Los cifrados están diseñados para ser lo más rápidos posible y, al mismo tiempo, ofrecen un buen nivel de seguridad para que pueda cifrar los datos de forma rápida y sencilla. Sin embargo, esta propiedad los hace malos para el cifrado de contraseñas, por lo tanto, tiene motivos como bcrypt que los ralentizan al iterar el algoritmo sobre la contraseña muchas veces.

Hubo una excepción con la que me encontré hace una década aproximadamente: el diseño era lento. El autor lo diseñó de esa manera porque no creía que los algoritmos rápidos fueran seguros. Si bien en general se consideró poco práctico, ya que llevaría mucho tiempo cifrar datos significativos y el diseño evitó que se usara en un entorno de transmisión, podría ser una buena base para un algoritmo de hashing de contraseña de una sola vía, suponiendo que el diseño sea correcto. criptográficamente seguro.

Hacer un cifrado lento no es un objetivo de diseño inteligente. Explicaré por qué más tarde, pero primero: Bcrypt. El propósito de Bcrypt es estirar una entrada de baja entropía a una salida más larga de una función unidireccional. Bcrypt está diseñado con contraseñas en mente. Las contraseñas generalmente tienen una entropía baja (< 2 ³⁰ ), pero si no lo hicieran, Bcrypt podría ser reemplazado por una función criptográfica hash normal. Una razón por la que no es necesario reducir la velocidad de los cifrados es porque es fácil generar claves de alta entropía. No es posible realizar operaciones bruscas con cifrado con claves grandes.

Permite comparar AES-128 con el cifrado hipotético BFT-256. (Nombrado como HAL / IBM). BFT es un millón de veces más rápido que AES-128. ¿Sería más fácil forzar la fuerza bruta la clave suponiendo que AES-128 proporciona 128 bits de seguridad y BFT-256 proporciona 256 bits de seguridad? No, porque el cifrado con una clave más grande requiere una fuerza bruta 2 ¹²⁸ tantas veces las claves, aunque cada cifrado se puede hacer 2 ²⁰ más rápido. 2 ^256-20 > 2 ¹²⁸ .

Finalmente, si alguien realmente quiso frenar un cifrado, aquí hay algunos ejemplos de lo que podrían hacer. Podrían aumentar el número de rondas en un cifrado de bloque. Sin embargo, esto aumenta la cantidad de tiempo que toma el cifrado de forma lineal para las personas con o sin la clave. La expansión del espacio de la clave aumenta la cantidad de tiempo que se tarda en aplicar la fuerza bruta a una clave de manera exponencial, al tiempo que hace una pequeña diferencia en el tiempo de cifrado según el algoritmo. Segundo, uno podría usar una clave secreta y un contador para construir un cifrado lento de Bcrypt de la misma manera que puede hacerlo con SHA y otras funciones hash. Sin embargo, espero que ambas soluciones parezcan tontas ahora.

Además, ni siquiera hay energía suficiente para incrementar un contador 2 ²⁵⁶ veces incluso si toda la energía Los productos producidos por una supernova podrían ser capturados y los cifrados consumen aún más energía y más tiempo que una operación de incremento.

Algunas funciones de hash (presumiblemente te refieres a hash, no a cifrado, ya que estás hablando de hashing de contraseña) son más lentas que otras. Como ejemplo, la implementación original de Bernstein CubeHash es comparativamente lenta, y DJB promociona su bajo rendimiento como un punto de venta. Sin embargo, nadie realmente lo compró.

Es necesario dedicar mucho esfuerzo a la industria para perfeccionar y asegurar una única función criptográfica, por lo que la función debe funcionar bien en todos los ámbitos. Y, además del uso en contraseñas de hash, las funciones de hash también se usan para cosas como la verificación de archivos y la firma de mensajes sobre la marcha.

Una función hash de funcionamiento lento es insalvable en los casos que necesitan un alto rendimiento, pero un hash de funcionamiento rápido puede hacerse lento simplemente ejecutándolo de forma iterativa, como ocurre en PBKDF2 y algoritmos similares de fortalecimiento de hash. Teniendo esto en cuenta, un hash rápido es universalmente más útil y, por lo tanto, es más probable que esté bien revisado y sea ampliamente implementado.