PBKDF2 utilizado para generar una clave de cifrado: secreto compartido de larga data (contraseña) contra el número de iteraciones

La línea de máquina AS / 400 tiene una larga historia. Normalmente usan la CPU de la familia PowerPC / POWER, pero los primeros modelos comenzaron con una CPU con una velocidad de reloj de 55 MHz, lo que no puede esperar que sea rápido ... Esto podría explicar el rendimiento abismal que obtiene. O quizás hubo algún problema sutil en su proceso de adaptación. Por ejemplo, el desenrollamiento agresivo del bucle puede hacer que un código de función exceda la memoria caché L1, lo que puede matar el rendimiento a lo grande (ya presencié una desaceleración de 50x para tales casos).

De todos modos, las iteraciones en PBKDF2 están diseñadas para compensar la entropía relativamente baja de la contraseña de entrada (porque la contraseña es una contraseña , que se ajusta a un cerebro humano). Si puede hacer que la contraseña tenga una alta entropía, obtendrá seguridad con un recuento de iteraciones bajo.

(Tenga en cuenta que la entropía no es la longitud. La entropía es aleatoriedad .)

Como su nombre lo indica, se utiliza una función de derivación de clave basada en contraseña (PBKDF) para obtener una clave de cifrado a partir de una contraseña . Las contraseñas son generalmente cortas (baja entropía) y el forzado bruto se puede hacer en un tiempo razonable. El PBKDF luego frustrará el uso de fuerza bruta usando mucho tiempo por cada intento.

Parece que tiene el control de la clave (no el usuario está eligiendo una contraseña), en este caso es seguro prescindir del PBKDF y usar la clave secreta directamente. Si su algoritmo por ej. espera una clave de 32 bytes, esta clave tiene una alta entropía y no se puede forzar en forma bruta en un tiempo razonable. Tenga en cuenta que esos 32 bytes no son un texto alfanumérico, sino que es como una matriz de 32 bytes aleatorios.

EDITAR:

Por su comentario, veo que de hecho es una contraseña, por lo que el PBKDF es la forma correcta de hacerlo. En realidad, es correcto que una contraseña larga (una contraseña con una alta entropía) permita disminuir el factor de costo, aunque la dificultad radica en garantizar que el usuario realmente elija una contraseña tan segura. Las reglas habituales no son un buen indicador, porque una contraseña como Password2014 o proverbios conocidos llena la mayoría de las reglas, pero no son contraseñas seguras. Una salida sería que su aplicación genere contraseñas seguras por sí misma y solo acepte contraseñas de este formulario.

  

Hay algún tipo de regla, como "agregar n caracteres a la contraseña   ¿Es algo equivalente a aumentar el número de iteraciones (c) de x?

La compensación entre la fuerza de la contraseña y el recuento de iteraciones es id: log, donde id es la identidad, y log es el logaritmo. Entonces, 1000 iteraciones significarían alrededor de 10 bits de fuerza de contraseña adicional. Un millón de iteraciones significaría 20 bits adicionales. Sin embargo, no existe una relación fuerte 1: 1 entre el número de caracteres en una contraseña y su fuerza en bits, solo para contraseñas verdaderamente aleatorias.

PBKDF es una solución muy mala para un problema que de otro modo sería aún peor. Solo añade logarítmicamente a la fuerza. Por lo general, PBDKF no genera tanta carga general, ya que incluso para grandes servicios, el número de personas que inician sesión en un momento dado es pequeño en comparación con el número total de usuarios. Pero en su caso, el problema de carga PBDKF se aplica claramente.