¿Es posible saber la clave si tenemos el valor original y el hash utilizando HmacSHA1?

No es posible obtener la clave dada esta información. De lo contrario, tendrías un problema de seguridad bastante serio. Muchos algoritmos de criptografía "completa" (y hash) tienen la razón de que saber pares de entrada-salida no hace que los atacantes estén más cerca de descubrir la clave. Esto a veces se denomina "desgaste de la llave", debido a que su llave se desgasta con el uso y se vuelve menos segura.

No es posible recuperar la clave ... asumiendo que la clave tiene suficiente entropía.

Esto es lo que el atacante puede hacer. Si el atacante tiene una conjetura en la clave, el atacante puede verificar si su conjetura es correcta. Esto significa que si el atacante puede reducir la lista de posibilidades de la clave a una lista lo suficientemente corta, el atacante simplemente puede probar todas las posibilidades en esa lista y ver cuál es la correcta, y el atacante eventualmente descubrirá el valor correcto de la lista. llave. Esta estrategia de ataque se conoce como búsqueda de fuerza bruta o búsqueda de teclas exhaustiva. Resulta que este es esencialmente el único ataque que puede hacer un atacante; con SHA1-HMAC, un atacante no puede hacer nada mejor que esta estrategia de ataque.

Por lo tanto, su trabajo como defensor es asegurarse de que la cantidad de posibilidades para la clave sea lo suficientemente grande como para que la búsqueda de fuerza bruta no tenga éxito. Idealmente, habría al menos 2 posibilidades ¹²⁸ para la clave, todas igualmente probables. Por ejemplo, puede generar la clave leyendo 128 bits de /dev/urandom . Si así es como seleccionas la clave, entonces no habrá forma de que un atacante la recupere.

Por otro lado, si haces un trabajo horrible como defensor de elegir la clave, entonces un atacante podría recuperar la clave. Por ejemplo, suponga que decide que su clave será un número aleatorio de 4 dígitos. Bueno, entonces solo hay 10,000 posibilidades para la clave, por lo que un atacante puede probarlas todas e identificar cuál es la correcta. El proceso de prueba y error tomará solo milisegundos, por lo tanto, si así es como seleccionó su clave, las cosas serían totalmente inseguras, y el atacante podría recuperar la clave. Si elige un número aleatorio de 10 dígitos como su clave, entonces hay 10 valores ¹⁰ posibles de la clave, que aún no son suficientes: un atacante podría probar todos esos valores posibles en meras horas. Entonces, no hagas eso. O, si usa el número de teléfono o el SSN de alguien como la clave, nuevamente, un atacante podrá recuperar la clave (simplemente probando todas las posibilidades). Entonces, tampoco hagas eso.

En resumen: elija su clave con 128 bits de aleatoriedad de criptografía. Entonces, no será posible que un atacante recupere la clave.

En general, intenta mantener el original seguro, y el salt se almacena de una manera menos segura, en general dentro de una tabla de base de datos junto con el nombre de usuario, o algo así. Estás preguntando lo contrario de lo que generalmente sucede.

Entonces, suponiendo que sal esté almacenado en algún lugar, y nadie haya tenido acceso a él, es tan "difícil de encontrar" como el original sería de la forma habitual.

Cuando las personas dicen que "usar un salt evita las tablas precalculadas", el salt tiene dos propósitos: hacer que su contraseña sea "más grande", para que no esté en un pre cubierto -el rango de la tabla de computación, y evitar que dos usuarios con la misma contraseña terminen con el mismo hash.

Si tienes una parte de ella secreta (la pieza original ) y otra que podría revelarse (la pieza salt ), estarás haciendo el atacante Vaya con fuerza bruta, ya que la pieza conocida ( sal ) se agregará a cada intento.

Lo que sucede cuando revela la pieza original y mantiene sal en secreto es que simplemente está invirtiendo los nombres: el original es la conocida, y la sal es la secreta. Por lo tanto, todas las observaciones sobre la dureza para encontrar el original cuando se sabe que el sal aún se aplica.

Un buen Código de autenticación de mensaje debería ser resistente a falsificaciones : imagina que lo malo Guy tiene acceso a un cuadro que calcula HMAC / SHA-1 sobre las entradas que elige y proporciona; internamente , el cuadro usa una clave secreta. El objetivo del atacante es construir un par (m, h) donde h es un MAC correcto para el mensaje m , sin usando m como entrada al cuadro. Si lo prefiere, el atacante alimenta las entradas N al cuadro e intenta terminar con los valores de MAC válidos de N + 1 . Recuperación de clave sería aún peor (si el atacante recupera la clave, entonces puede producir tantos pares de (m, h) que desee).

Si la salida de MAC tiene longitud n bits, y el atacante puede tener éxito enviando menos de 2^n-1 a la casilla y gastando menos de 2^n-1 invocaciones de MAC por valor de CPU, el algoritmo de MAC se declara "roto" (al menos de manera académica). Actualmente, HMAC / SHA-1 NO está roto (incluso académicamente), y dado que su salida es de n = 160 bits, y un esfuerzo de CPU de 2 ¹⁵⁹ es totalmente fuera del alcance de la humanidad , podemos decir que nadie puede producir falsificaciones en HMAC / SHA-1, y mucho menos recuperar la clave, dados los pares de entrada / salida (incluso si el atacante elige el valores de entrada en estos pares).

Lo anterior supone que la clave se toma de un conjunto de posibles claves de tamaño al menos 2ⁿ . Si usa una clave con menos de n bits, entonces el atacante puede probar secuencias aleatorias de n hasta que se encuentre una coincidencia. Ese es el ataque de búsqueda exhaustivo genérico . Si la clave tiene una longitud de al menos 80 bits, esto no es posible con la tecnología actual (con una clave de 128 bits, tiene un margen de seguridad muy importante). Entonces, nuevamente, esto supone que el conjunto de claves posibles es realmente tan grande, es decir, que usaste un criptográficamente fuerte PRNG para generar la clave - vea la respuesta de @DW para más detalles.