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 ;-)