So if I understand you correctly, hosts A and B have a piece of information and A wants to know whether B still possesses it. Why not just ask B to send the data to A?
If the data is large, you might want to hash it and have B send the hash to A. Without the data, B can never make the correct hash.
However, B could generate it once, store the correct hash, and throw the data away. If you want to prevent this, you could use a challenge response system where you have A generate a random number (with a CSPRNG), send it to B, and B has to hash the data together with the random number and send the result to A. Since A has both the correct answer and the number, it can perform the same operation and validate the result.
If you use an HMAC with the random number and the data as the two parameters, I think that should be secure. However, since we're sort-of inventing our own crypto here, you might want to ask https://crypto.stackexchange.com to verify that when computing
hash = HMAC(number, data) and storing both the hash and the number (and perhaps intermediate values of the HMAC operation), one cannot compute the correct hash for a new number without the original data.
I wonder why you need this, though. I cannot think of a place where this is currently in use, so I wonder whether there isn't simply an existing solution to the problem you are trying to solve, instead of doing this complicated system with "continued possession of the information".
Oh and Keccak has nothing to do with this. HMACs prevent hash length extension attacks, you don't need to use one specific hash function for that. SHA2 and SHA3 are both fine. There is also no point in hashing an encrypted version. Why bother with encryption? It sounds a bit like you're making crypto soup ;-)