Almacene un Hash criptográfico con capacidad de búsqueda

Si necesita un sistema realmente seguro con salazón y estiramiento de llaves, entonces no hay manera de hacer que se puedan buscar los hashes. Es el mismo problema que con el almacenamiento de contraseñas:

• Con la aplicación de sal, previene los ataques de la tabla del arco iris, pero uno tiene que leer la sal antes de poder verificar el hash de datos.
• Con el estiramiento de las teclas (haciendo que el hash sea lento) puede frustrar los ataques de fuerza bruta, pero uno no puede verificar rápidamente muchos / todos los hashes de datos.

Esto hace que el uso de hashes seguros y la capacidad de búsqueda sean mutuamente excluyentes. Depende del nivel de seguridad requerido, si puede prescindir de la sal o si puede cambiar a un cifrado menos seguro.

Una forma de salir de este problema podría ser, para cifrar los datos, sin almacenar la clave. Esto requiere que el usuario ingrese una contraseña cada vez que use el servicio. A partir de esta contraseña de usuario, generará una clave con una función de derivación de claves y mantendrá la clave en la memoria todo el tiempo que sea necesario.

Podría considerar usar una firma separada en lugar de un simple valor de hash, si su aplicación no es vulnerable al "aprenda el ataque de información restante" .

Por ejemplo: Alice tiene una base de datos de documentos confidenciales en una computadora segura que normalmente está apagada. Antes de que se apague esa computadora, Alice usa esa computadora con la clave privada de esa computadora para firmar criptográficamente cada documento, generando una firma separada diferente para cada documento. (El algoritmo de firma criptográfica utiliza internamente un algoritmo hash criptográficamente seguro para generar un valor de hash de ancho completo). Luego, Alice copia esas firmas extraídas en una memoria USB y luego la coloca en un servidor separado que Alice mantiene encendido y permite que el público acceda.

Más tarde, Bob tiene un documento presuntamente sensible en la mano y se pregunta si es el mismo que uno de esos documentos anteriores. Así que Bob tiene el documento en mano usando el mismo algoritmo hash y usa el algoritmo de verificación estándar para ver si verifica contra alguna de las firmas separadas. (Hay un valor hash truncado de 16 bits almacenado en cada firma separada de PGP estándar, por lo que el software podría escribirse para utilizar una búsqueda binaria para encontrar rápidamente cualquier firma que pueda coincidir, si hay cualquier coincidencia, use el algoritmo lento de clave pública para verificar). El resultado siempre será uno de:

• No coincide: No, ese documento definitivamente no está en la computadora protegida.
• Coincidencia: Sí, ese documento definitivamente estaba en la computadora protegida.

(Se considera prácticamente imposible tener falsos positivos o falsos negativos).

detalles:

• "¿Cómo verifica una clave pública una firma?"
• "Cómo se separan las firmas ¿Se utiliza para verificar la integridad y autenticidad de un archivo? "
• "¿Qué sucede cuando verifica una firma separada?"
• "Haciendo y verificando firmas"

Si tiene relativamente pocos fragmentos de texto (por ejemplo, alrededor de N = 1000 fragmentos de texto), y está bien que su sistema dé ocasionalmente un "falso positivo", puedes considerar usar un hash truncado.

Por ejemplo: Alice tiene una base de datos de alrededor de N = 1000 documentos confidenciales en una computadora segura que normalmente está apagada. Alice está dispuesta a tener un índice de error falso positivo de e = 1/100. Antes de que la computadora se apague, Alice la usa con cualquier función hash segura criptográficamente (SHA-3, BLAKE, Argon2, etc.) para codificar cada documento (quizás utilizando el mismo valor de sal publicado públicamente para los 1000), luego truncar el hash a log2 (N / e) = log2 (1000 * 100) = alrededor de 17 bits, luego copie esos hashes truncados de 17 bits en una memoria USB y luego coloque esa memoria USB en un servidor separado que Alice mantiene encendido y permite que el público acceda.

Más tarde, Bob tiene un documento presuntamente sensible en la mano y se pregunta si es el mismo que uno de esos documentos anteriores. Así que Bob tiene el documento a mano y compara su hash truncado de 17 bits con cada uno de los aproximadamente 1000 valores de hash en el servidor (posiblemente utilizando una búsqueda binaria relativamente rápida). El resultado siempre será uno de:

• No coincide: No, ese documento definitivamente no está en la computadora protegida
• Coincidencia: ese documento podría estar en la computadora protegida.

Este algoritmo es bastante resistente a "aprender el ataque de información restante", porque hay tantos falsos positivos que es difícil para un atacante descubrir cuál es la información restante real.

Si alguien genera aleatoriamente un grupo de documentos (ninguno de los cuales coincide exactamente con ninguno de los documentos confidenciales), espero que aproximadamente el 1% de esos documentos tengan un valor hash coincidente coincidente, dando el "falso positivo" de "Eso El documento podría estar en la computadora segura ". El 99% restante de esos documentos indica "No, ese documento definitivamente no está en la computadora protegida".