Función de hash en expansión / inversa

4

Primero que nada, antes de hacer mi pregunta, déjame explicarte lo que NO estoy preguntando. NO estoy pidiendo una forma / método para revertir una salida de hash; por definición, una función de hash es unidireccional.

¿Existe tal cosa como una función de hashing inverso? Probablemente lo estoy llamando el nombre equivocado. Lo que quiero decir es una función donde, por ejemplo, si la entrada tiene una longitud de 100 caracteres, la salida tendrá una longitud de 150 caracteres. Por lo tanto, un hash unidireccional donde la salida siempre es más grande que la entrada. Sin embargo, los hashes tradicionales generalmente hacen que la salida sea más pequeña que la entrada (si la entrada es de un tamaño razonable).

No soy un experto en seguridad, por lo que estoy abierto a la posibilidad de que me equivoque. Sin embargo, me parece que este tipo de hash con una salida más larga sería más difícil de descifrar con una tabla arco iris, etc. Por supuesto, sería menos útil que un hash tradicional para cosas como asignar una imagen a una ID, pero Aplicaciones de seguridad, ¿podría ser superior? Y, por supuesto, la relación entre el tamaño de la entrada y el tamaño de la salida no necesita ser fija, por lo que es mucho más difícil predecir la entrada.

    
pregunta TheCatWhisperer 04.04.2013 - 22:04
fuente

5 respuestas

3

Hashing es una manipulación algorítmica de datos. Una función de hashing criptográfica es una función de sentido único con un tamaño de salida fijo independientemente del tamaño de entrada.

Parece que hablas de aumentar la seguridad al utilizar un tipo diferente de función hash, así que no ... ningún hash criptográfico coincide con las propiedades que no describí anteriormente. Para otros tipos de hashing (en particular con respecto a las estructuras de datos), consulte enlace .

De lo contrario, la respuesta es no y el alargamiento variable de la entrada no sería una mejora, ya que es imposible generar más entropía sin agregar más información. No se pueden agregar más entradas, ya que la función hash de una vía debe ser repetible para que sea útil.

    
respondido por el Jeff Ferland 04.04.2013 - 22:35
fuente
2

No hay ganancia de seguridad, para el hash de contraseñas, para tener un resultado de hash más largo. El atacante intenta "contraseñas plausibles" hasta que se encuentra una coincidencia con el valor hash almacenado. El espacio de contraseñas que intentará el atacante (independientemente de cómo los intenta, por ejemplo, con una tabla de arco iris) será muy pequeño, en términos absolutos (menos de 2 80 ). En consecuencia, el atacante solo necesita trabajar con los primeros 80 bits del valor hash, incluso si almacenó 2000 bits de salida: 80 bits son suficientes para el atacante, ya que no obtendrá muchos "falsos positivos".

El meme "más grande es mejor" es fuerte en la industria, pero en criptografía es bastante incorrecto.

Dicho esto, es posible generar una salida larga desde una entrada pequeña; este es el principio de funcionamiento de cifrados de flujo . Una forma sencilla es codificar la contraseña con una función de hashing de contraseña normal (consulte este ) y luego use la salida de hash como clave para un cifrado de flujo (por ejemplo, uno de estos ). Hubo una función hash que combinó ambos pasos, llamada Panamá (resultó ser débil, pero no por ese motivo, algunos de los principios de Panamá se reutilizaron en el nuevo SHA-3, también conocido como Keccak ).

    
respondido por el Thomas Pornin 05.04.2013 - 13:28
fuente
1

Para agregar a la respuesta de Jeff Ferland , específicamente no haría más difícil la creación de tablas de arco iris, computacionalmente, dado Algoritmos que son computacionalmente equivalentes. Solo requeriría espacio de almacenamiento adicional para la salida de las tablas del arco iris. Sin embargo, esto es insignificante desde el punto de vista de la seguridad, ya que las tablas de lluvia se han vuelto obsoletas en gran medida con el uso generalizado del hash salado y el poder de cómputo relativamente económico al que ahora tenemos acceso debido a la Ley de Moore y las GPU modernas.

Entonces, si necesito calcular todos los hashes posibles para una entrada dada + una sal dada en cualquier caso, el tamaño de la salida es esencialmente irrelevante.

    
respondido por el Xander 04.04.2013 - 22:54
fuente
0

Algo que se aproxima mucho a esta descripción es un KDF , o estiramiento de teclas , por ejemplo. PKCS # 5 PBKDF2 . La intención de tal esquema (en ausencia de un esquema de hashing de contraseña más adecuado, como bcrypt ) es hacer bruta forzar la contraseña elegida por un usuario (ataque basado en el diccionario) es más costosa que un ataque de fuerza bruta en todo el dominio de entrada.

Aunque la salida del KDF no siempre tiene más bits que una contraseña arbitraria elegida por el usuario, es más "opaca" y puede ser más larga que la longitud mínima de la contraseña (aunque no puede agregar entropía, como se señala en La respuesta de Jeff Federland).

El tamaño de la salida de hash no es un buen indicador de resistencia a los ataques de la tabla arco iris, la sal es .

    
respondido por el mr.spuratic 05.04.2013 - 00:31
fuente
0

No estoy seguro de a qué te refieres. Hay dos categorías principales de usos de un hash criptográfico.

  1. Para verificar la integridad de un archivo grande con una suma de verificación entregada de forma segura. Por ejemplo, la suma de comprobación se entrega a través de un canal seguro (por ejemplo, https desde un sitio conocido), mientras que el archivo se transmite a través de un canal no seguro pero se compara con la suma de verificación al final, y

  2. Para autenticar la identidad de un usuario a través de una contraseña sin almacenar la contraseña en texto sin formato en una base de datos. Es decir, si mi contraseña es Correct Horse Battery Staple , almacenaría $2a$12$5vc0XINA0MiPvgE3ffLnaOVGqrMeskLKjFvIg4BKryq3v5PXt1oIi como un hash bcrypt de 184 bits en mi base de datos (con un salt de 128 bits). Cuando un usuario que conoce la contraseña secreta inicia sesión, el servidor compara el hash generado a partir de la contraseña (y salt) con el hash almacenado y solo los ingresa si coinciden.

La posibilidad de que un atacante adivine aleatoriamente el hash en una prueba tiene 1 oportunidad en 2 {longitud de bit del hash} . Entonces, para un hash de 256 bits, un atacante tiene 1 en 115792089237316195423570985008687907853269984665640564039457584007913129639936 posibilidad de adivinar aleatoriamente el hash en un intento (e incluso si los dejas probar por mil millones de segundos por segundo para un millón de unidades en el poder de un centavo). La contraseña de ~ 10 34 y su posibilidad de solo romper con éxito la contraseña es de solo 1 en 10 42 (por ejemplo, la posibilidad de ganar el powerball es de 1 en 10 ^ 8; por lo que es similar a su posibilidad de jugar al powerball cinco veces consecutivas y ganar el premio mayor cada una de esas cinco veces. Y nuevamente, eso fue para un hash de 256 bits, un hash de 184 o 512 o 1024 bits sería exponencialmente más fuerte. p>

Ahora, si tienes un hash que tiene un tamaño no fijo, parece ser contraproducente. P.ej,. transfiere un archivo de 1 GB a través de Internet, ¿realmente desea calcular una suma de comprobación en una suma de comprobación del mismo tamaño o mayor? Además, eso filtraría información sobre los datos que se hash. Por ejemplo, si su función de hash aumenta en longitud en dos bytes por cada byte agregado, puede encontrar la longitud de la contraseña original; lo que podría ser útil para encontrar rápidamente las contraseñas más cortas para intentar la fuerza bruta mediante la búsqueda en el diccionario de contraseñas de esa longitud. Y nuevamente, 2 256 ya es lo suficientemente fuerte como para superar a cualquier atacante factible, no hay necesidad de intentar usar un hash de 1 GB de tamaño para evitar que un atacante pueda hacer 2 8589934592 intentos, ya que no hay forma viable de hacer 2 256 incluso con suposiciones muy poco razonables.

Dicho esto, expansión de la clave , es decir, tomar una clave pseudoaleatoria de una longitud relativamente corta dada (como 128 bits / 256 bits) y luego usarla como "semilla" "para crear muchas más claves pseudoaleatorias (de longitud total mucho más larga que la clave original) se usa comúnmente para muchos propósitos criptográficos. Por ejemplo, en AES128, una clave de 128 bits se expande en 11 claves redondas que son de 128 bits (por ejemplo, 1408 bits en total) que se utilizan en cada ronda del proceso de cifrado AES.

De manera similar, un cifrado de flujo es a menudo esencialmente una expansión de clave; por ejemplo, puede construir un cifrado de flujo a partir de un cifrado de bloque que funcione en modo contador. Básicamente, digamos que tiene un cifrado de bloque (como AES256) donde toma un bloque de datos P de 256 bits, una clave K de 256 bits, y puede obtener un texto cifrado de una función de cifrado como C = E (K, P). Bueno, si comienza con un P de 256 bits aleatorio, puede crear un flujo pseudoaleatorio de longitud muy larga utilizando C0 = E (K, P) para los primeros 256 bits, C1 = E (K, P + 1) para los siguientes 256 bits , C2 = E (K + 2) para los siguientes 256 bits. Y puedes hacer esto para tener una transmisión pseudoaleatoria que puedas XOR con tu mensaje. Y puede hacer esto por muchos terabytes de datos antes de que los ataques sean factibles computacionalmente.

Sin embargo, no llamaría al cifrado de expansión / flujo de clave al contrario de un hash. Solo son cosas diferentes.

    
respondido por el dr jimbob 05.04.2013 - 00:24
fuente

Lea otras preguntas en las etiquetas