In my first post about HC modes I presented six block cipher modes of operation that provide forward secrecy right at the block level. These schemes rely on a ideal hash function to provide forward secrecy and privacy (this last property also requires an ideal block cipher). It turns out that this is not the only way to encrypt at a low level with forward secrecy. An idea (although flawed) was proposed here. The correct version of this idea is the following (and I suppose this idea has popped up many times in the past)
BUFFER[0]=Hash (EK || IVK) (the buffer is 256 or 512 bits wide)
BUFFER[i] =Hash(BUFFER[i-1])
Encryption: C[i] = TRUNC-128(BUFFER[i]) XOR P[i]
TRUNC-128(x) is a function that takes the first 128 bits of the argument x.
This scheme is similar to Hash Chain Prefix (HCP) block cipher mode, but without encryption!
There is nothing specially wrong with skipping the block encryption operation if care is taken to keep enough private state of the hash chain. The only problem I see is that we are rising the bet on the strength of the Hash function: it must now withstand the forward secrecy security and all the encryption security. That could be too many eggs for a single basket. Most HC modes, when used along a counter appended to each plain-text buffer after the hash, have lower security requirements for the Hash function: an ideal Hash function provides forward secrecy, and the ideal encryptor provides privacy.
By using the Hash function only to support the forward secrecy property we can prove that the resulting encryption scheme is no weaker than the original CTR mode.
Bitslog 