¿Existen implementaciones de algoritmos de hashing de contraseña para los marcos principales que utilizan hardware especializado como GPU / FPGA?

3

Es de conocimiento general que los intentos de descifrado de contraseñas pueden beneficiarse enormemente de hardware especializado como grandes grupos de GPU o FPGA.

¿Existen implementaciones de los algoritmos de hash de contraseña comúnmente recomendados (PBKDF2 / bcrypt) para lenguajes de programación y / o marcos comunes o populares como .NET que descargan la parte de hashing de contraseña del proceso de autenticación en hardware especializado como GPU o ¿FPGAs?

Si no existe una biblioteca de este tipo, ¿existen buenas razones para que no existan?

    
pregunta Ayrx 28.06.2013 - 16:00
fuente

3 respuestas

2

Como señala @Rook, la mayor parte de las ventajas de hardware especializado como GPU es a través de la paralelización. Un solo núcleo de GPU, por sí mismo, es bastante débil; se sincroniza a una frecuencia inferior a la de la CPU principal y solo computará una operación por ciclo de reloj (en el mejor de los casos, y con una latencia alta). Sin embargo, una GPU incluye cientos de núcleos que bailan simultáneamente.

Ahora, sucede que las funciones de hashing de contraseña habituales son inherentemente secuenciales. Ver, por ejemplo, PBKDF2 : cada fragmento de salida se calcula como el resultado final de una secuencia de U i valores, donde Ui+1 se obtiene al procesar Ui con un PRF (normalmente HMAC). Esto no puede hacerse paralelo. Si desea calcular una única instancia de PBKDF2 en una GPU, entonces usará solo un núcleo en esa GPU, y esto será muy lento. De hecho, un núcleo de GPU típico puede iniciar una instrucción por ciclos de reloj, pero el resultado estará disponible solo diez o veinte ciclos más tarde, por lo que la GPU se utiliza a su máxima potencia solo si tiene miles de tareas para correr en paralelo.

El atacante se beneficia de la GPU porque, por definición, el atacante tiene muchas contraseñas potenciales para probar. Para que pueda usar la computación paralela en toda su potencia; el forzamiento de contraseñas es un problema vergonzosamente paralelo . De hecho, ya que cada núcleo de GPU El defensor , por otro lado, no tiene mucho hashing: solo uno por cliente entrante a la vez. Podríamos imaginar un servidor muy ocupado con, en cualquier momento, cientos de clientes que intentan abrir una sesión, y eso podría ser optimizado con una GPU, pero esto no es muy realista.

Por lo tanto, no hay una implementación lista para usar de un marco de autenticación que descargue el costo de PBKDF2 o bcrypt en una GPU porque no funcionaría. En el contexto de la autenticación de los clientes entrantes (la situación del defensor), el mejor hardware para usar es la CPU, no una GPU.

Dicho esto, esto se debe a que PBKDF2 y bcrypt (y también scrypt y la mayoría de las otras funciones del mismo tipo) son secuenciales. Se podrían diseñar funciones de hashing de contraseñas que se pueden hacer en paralelo. Como ilustración, imagine una función de hashing de contraseña lenta diseñada de esta manera:

  • La contraseña es pw , la sal es s .
  • Para i = 1 a 10000 , defina V i = PBKDF2 ( pw || i , s ).
  • El valor de hash final es SHA-256 ( V 1 || V2 || ... || V10000 ).

En el caso de esa función, la mayor parte del esfuerzo computacional son las diez mil instancias de PBKDF2, que pueden optimizarse con una GPU, incluso si solo tiene una contraseña para el hash.

( Precaución: la función anterior se presenta solo como una ilustración especulativa. ¡No creas que es seguro! Esto no ha sido revisado por muchos criptógrafos entrenados durante varios años. )

Existe una competencia en curso para definir nuevas primitivas de hashing de contraseñas, con el mismo espíritu que los esfuerzos de AES, SHA-3 o eSTREAM. . Si tiene algunas ideas ingeniosas acerca de la definición de una función de hashing de contraseña susceptible de paralelismo, entonces, por supuesto, considere enviar un candidato.

    
respondido por el Tom Leek 28.06.2013 - 19:24
fuente
1

El beneficio de las funciones de cálculo de hash con un FPGA o GPU es que son muy paralelas, por lo que la mayoría de los sistemas de autenticación no requieren esta paralelización. Además, las funciones hash intensas de memoria, como bcrypt y scrypt, eliminan la ventaja de la paralelización que los FPGA y las GPU tienen sobre las CPU.

Es posible implementar una característica de este tipo, sin embargo, sería contraproducente. El punto de usar bcrypt, y otros algoritmos de estiramiento clave, es eliminar la ventaja computacional proporcionada por un recurso computacional altamente paralelizado como un FPGA o GPU.

Relacionados: ¿Por qué no se puede un bcrypt impermanente en Cuda ?

    
respondido por el rook 28.06.2013 - 17:26
fuente
0

Eche un vistazo al código de minería de bitcoin: todo su proceso se basa en el cálculo de hashes SHA-256, y sé que no solo existen implementaciones de GPU, sino también FPGA y ahora incluso ASIC que aparecen.

Un dispositivo basado en ASIC disponible hoy por $ 1300 puede pasar por cerca de 66,300,000,000 SHA-256 hashes por segundo. Una tarjeta de video ATI / AMD 7970 puede hacer aproximadamente 687,000,000 hashes por segundo.

    
respondido por el tylerl 29.06.2013 - 08:08
fuente

Lea otras preguntas en las etiquetas