¿Puede HMAC confirmar la existencia del mensaje?

1

Estaba buscando HMAC y me preguntaba si un HMAC puede verificar la existencia de un mensaje.

Necesito verificar que otro host (aún) tiene una gran cantidad de datos. Planeo enviar una clave al host y esperar un hash computado. Estoy considerando uno de los siguientes métodos para que el host genere una clave única que confirme la existencia continua de los datos:

  • Hash (cifrar (k, m))
  • HMAC (k, m)

Me preocupa que pueda haber una manera de agrupar los datos, almacenarlos y utilizarlos en el cálculo de HMAC, similar a los ataques de extensión de longitud.

Estoy usando Keccak que, como lo entiendo, debería ser resistente a esto.

¡Gracias!

EDITAR: Referencia cruzada de preguntas orientadas a Crypto en cryptostack

    
pregunta deadfire19 27.04.2017 - 21:59
fuente

3 respuestas

1

Lo que necesita aquí se llama apropiadamente hashing aleatorio : conceptualmente, una familia de funciones hash seguras, de las cuales elige miembros al azar y los usa para hash mensaje. Por lo general, estos se implementan como funciones de dos argumentos que toman una "clave" o "sal" como primer argumento, pero es importante entender que esta "clave" no es (potencialmente) destinada a sé secreto : pueden ser revelados a los adversarios.

Los MAC en general no hacen buenos hashes aleatorios, porque el objetivo estándar de seguridad de MAC es para claves secretas , claves que solo conocen las partes honestas y no los adversarios. Pero HMAC, a pesar de que el nombre es más que un MAC, se basa en una función hash segura, por lo que puede usarse tanto como MAC y como una función hash aleatoria.

Entonces la respuesta corta es sí, pero no se confunda con el nombre de HMAC en este caso; HMAC funciona aquí porque es una buena función hash , no porque sea un buen MAC. Y si tiene una buena función hash, no necesita HMAC para esto: hash(salt || msg) debería funcionar bien. Yo uso HMAC, sin embargo.

    
respondido por el Luis Casillas 29.04.2017 - 04:56
fuente
0

Entonces, si te entiendo correctamente, los anfitriones A y B tienen una información y A quiere saber si B todavía la posee. ¿Por qué no pedirle a B que envíe los datos a A?

Si los datos son grandes, es posible que desee hacer un hash y que B envíe el hash a A. Sin los datos, B nunca puede hacer el hash correcto.

Sin embargo, B podría generarlo una vez, almacenar el hash correcto y desechar los datos. Si desea evitar esto, puede usar un sistema de respuesta de desafío donde tiene A generar un número aleatorio (con un CSPRNG), enviarlo a B, y B tiene que agrupar los datos junto con el número aleatorio y enviar el resultado a A. Dado que A tiene tanto la respuesta correcta como el número, puede realizar la misma operación y validar el resultado.

Si utiliza un HMAC con el número aleatorio y los datos como los dos parámetros, creo que debería ser seguro. Sin embargo, dado que estamos inventando nuestro propio criptografía aquí, es posible que desee preguntar a enlace para verificar que al calcular hash = HMAC(number, data) y almacenando tanto el hash como el número (y tal vez los valores intermedios de la operación HMAC), no se puede calcular el hash correcto para un nuevo número sin los datos originales.

Me pregunto por qué necesitas esto, sin embargo. No puedo pensar en un lugar donde esto esté actualmente en uso, por lo que me pregunto si no hay simplemente una solución al problema que está tratando de resolver, en lugar de hacer este sistema complicado con "posesión continua de la información".

Oh y Keccak no tiene nada que ver con esto. Los HMAC previenen los ataques de extensión de hash, no es necesario usar una función hash específica para eso. SHA2 y SHA3 están bien. Tampoco tiene sentido hash una versión encriptada. ¿Por qué molestarse con el cifrado? Suena un poco como si estuvieras haciendo sopa criptográfica ;-)

    
respondido por el Luc 28.04.2017 - 00:26
fuente
0

Creo que la solución más sencilla es que usted precompute un conjunto de hashes de offset + length y luego envíe una solicitud con uno de estos pares de longitud y offset de vez en cuando.

Independientemente de lo que haga, debe realizar las mismas operaciones con anticipación si espera eliminar los datos que está cargando, y este método impone la carga más baja al proveedor de almacenamiento.

    
respondido por el adamant 29.04.2017 - 00:38
fuente

Lea otras preguntas en las etiquetas