Transfer and hide ciphertext with hash functions?

Question

Can hash functions be used to transfer and hide ciphertext?

This somewhat similar locked question, "If cryptographic hashes are completely unique, could they theoretically be used to transfer data?", received several cogent no answers, but consider this:

Alice and Bob share a secret:

/p68J5gd3%}"jd9fkg;BtiAraGgsioe2:L<76e7emOngehf]jfur80}{_kod*6

Alice adds her ciphertext JWHSM to her copy of the secret:

/p68J5gd3%}"jd9fkg;BtiAraGgsioe2:L<76e7emOngehf]jfur80}{_kod*6 || JWHSM

Now she hashes (secret + message) with SHA-512 and sends the hash to Bob.

Bob knows that he has to do a bit of computation and find the ciphertext that will concatenate and resolve to the hash value he has been sent by Alice, and he knows how many characters there will be (5 in this case). So, in effect, Alice sent Bob a message he could not immediately read, but he can resolve it. They want to defeat certain aspects of traffic analysis, and they suspect that Mr. Attacker might be able to make easy preimage attacks on every hash they send--to which they respond "So what?"

Can hash functions be used to transfer and hide ciphertext in this unorthodox, expensive manner?

Answer 1

Yes, you can use a hash to "hide" messages like that. However, I don't see any advantage of this compared to normal symmetric encryption, which already is able to return a well randomized ciphertext.

Randomization in itself is not steganography as I've understood it. A fully randomized message may stand out, both on its own and when simply copied into a message. Let's perform a little thought experiment: with a bit of trouble you can create a block cipher with a block size identical to the output size from a hash function. I don't see how your scheme would be any different from that particular cipher or fare any better in hiding the plaintext / ciphertext.

Lets look at the drawbacks:

1. First of all, there is this relatively high amount of work to be performed by the receiving party.
2. Second, the method scales terribly bad. You can probably only have $2^{32}$ plaintext / ciphertext pairs, and that's already stretching CPU resources.
3. Thirdly, the ciphertext is much larger than it needs to be, even if it is static and limited to the output size.
4. And finally, as there is no IV, it is not semantically secure if you'd send multiple messages as the ciphertext would repeat.

As for the 4th point: introduction of a fully random IV send with the ciphertext is of course possible, but it would expand the ciphertext even further.

---

I can see some advantage if this code is used when a hash is already used, e.g. when authenticating an unencrypted message (or encrypted message with a known size) in signature generation or HMAC. In that case the other data is already present and doesn't need to be guessed. The scheme could then be used to create a subliminal channel, which is related to steganography I guess.

Of course you would want to make sure that the additional message is stuck at the end, rather than in front, so that you only have to hash the send message only has to be hashed once (except maybe for the last block). As for signature generation: you'd probably want to use PKCS#1 v1.5 padding to retrieve the full hash. Note that for signatures an adversary will be able to see that the original hash / signature doesn't verify, which kind of negates the hiding of the message.