# Hash function from narrower block cipher operated in CBC-encryption mode?

I am trying to build a public hash function (thus collision-resistant and preimage-resistant, and more generally behaving like a random oracle), with input a message $M$ of fixed size $|M|=m\cdot b$ bits, and output the hash $H(M)$ of fixed size $|H(M)|=h\cdot b$ bits, using as the single primitive a $b$-bit block cipher with key of $k\cdot b$ bits, operated in CBC-encryption mode.

One of the motivation of the construction is to maintain the confidentiality of the message under DPA attacks, assuming that the implementation of the cipher in CBC-encryption mode is DPA-protected. I thus require that all message-dependent data is manipulated using the $P$ and $K$ inputs of that trusted primitive: $$F(K,IV,s,P)\to C\text{ with }|K|=k\cdot b,|IV|=b,s>0,|P|=|C|=s\cdot b,$$ $$C[0]=\text{ENC}_K(P[0]\oplus IV), C[j]=\text{ENC}_K(P[j]\oplus C_{j-1})\mathsf{\text{ if }}1\le j<s.$$

I would like security beyond that of the underlying block cipher by a security parameter $q$, with an argument that any attack requires $2^{b\cdot q}$ queries to an encryption or decryption oracle implementing $\text{ENC}$ and the corresponding decryption, for some suitable definition of security/attack which, uh, is part of the question (in particular it seems necessary to restrict the amount of memory usable by the attacker, including but not limited to as a cache for the oracle). Performance is secondary (one envisioned application is a slow KDF), a security argument (or better proof) is a must, simplicity matters.

Assume there is enough memory for the whole message, and then some. Assume at least $\min(b,k\cdot\lceil b/2\rceil)$ bits of the block cipher's key are effective (which rules out simple-DES). A typical setup could be 3DES thus $b=64$, $k=3$, and $m=64$ ($4096$-bit input), $h=8$ ($512$-bit output), $q=4$ (security of $2^{256}$ block cipher queries or memory accesses). Assume $m\ge h>1$, and if that helps assume $m\gg h$ or/and $h\gg k$ or/and $k=1$ (e.g. AES-128, ignoring attacks marginally reducing its effective key size).

What appropriate definition(s) of security are applicable?
I apologize for late realization that this is an issue, and corresponding introduction of security parameter $q$. I now think I want a collision-resistant Universal One-Way Hash Function family per this terminology.

Is there some standard construction that fits?
My review of the existing found a few hashes made from block ciphers, but suitable for $h\le2$ only, not neatly constructible from my primitive when $h>1$, and aiming at efficiency rather than a strong security argument.

If nothing standard exists, my simplest candidate is the following CBC-HASH:

• assume an arbitrary public parameter $P$ of $p\ge k$ blocks which right $k$ blocks are suitable as an initial key for the cipher ($P$ parameterize the UOWHF family; in the simplest/original setup, $p=k$);
• append $P$ to message $M$ forming $X_0$ of $m+p$ blocks $X_0[j]$, that is $M[j]\to X_0[j]\mathsf{\text{ if }}0\le j<m, K[j]\to X_0[m+j]\mathsf{\text{ if }}0\le j<p$;
• repeat for $n$ rounds, numbered $r$ from $0$ to $n-1$:
• set $K_r$ as the right $k$ blocks of $X_r$, that is $X_r[m+p-k+j]\to K_r[j]\mathsf{\text{ if }}0\le j<k$;
• CBC-encipher $X_r$ using key $K_r$ and the $b$-bit big-endian representation of $r$ as $IV$, giving $X_{r+1}$, that is $F(K_r,(r)_b,m+p,X_r)\to X_{r+1}$;
• set output $H=H(M)$ as the right $h$ blocks of the left $m$ blocks of $X_n$, that is $X_r[m-h+j]\to H[j]\mathsf{\text{ if }}0\le j<h$.

Now I am wondering how the number of rounds $n$ and the size $p$ of the initial padding shall be chosen from $q$, $h$, $m$, $k$ (perhaps $b$), and the limits on parameters for a security argument.

Can you justify, prove, improve, break, or fix CBC-HASH?
The scheme now incorporates parameter $p$ controlling the size of the UOWHF family. I retract an earlier guess on $n$ made without even a clear security definition. I hereby vow to stop modifying this question except for fixing obvious typos; any addition will be an answer.

-
Normally my advice is "never roll your own", but... Holy crap! – Polynomial Jul 11 '12 at 20:00

2
@Polynomial well someone has to build those, they don't design themselves, right? :p – Thomas Jul 12 '12 at 1:21
I removed the community wiki status from this question, so answerers can get their reputation, too. – Paŭlo Ebermann♦ Jul 18 '12 at 12:38

## 1 Answer

If the motivation is to rely on a DPA protected implementation of a block cipher, hash function constructions based on a block cipher (think of Davies-Meyer for instance with say Rijndael at 256-bit plaintext) could be used. Alternatively, the issue of using small input size compression function to built secure hash functions with larger output size has been investigated in e.g. Nandi, INDOCRYPT 2005; Hirose, FSE 2006; Peyrin et al., Asiacrypt 2006 and following work, but is not entirely settled.

From an efficiency point of view, CBC-HASH is going to be at least $n$ times slower than any other hash function in the wild. (And practical security is always a balance between practicality, that is resources, and security.) In addition, the hash cannot be computed on the fly: one has to make $n$ passes over the message which is cumbersome in many scenarii (think embedded devices for instance).

Case $n=1$. Assuming the underlying block cipher is denoted by $E$, take whatever you want for the message blocks $M_i=N_i$, $l>i>1$ for some big $l$ and:

• $M_0=0$ and $M_1=E_K(R)$,
• $N_0=R$ and $N_1=E_K(0)$.

for some $R\neq 0$ if $IV=0$ and $R=IV$ otherwise. Then, note that the hash output is the same, so that you have a collision for $M$ and $N$. This is possible because $K$ and $IV$ are known values.

Case $n=2$. Choose some index $\xi$ and choose the message blocks $M_1$, ..., $M_\xi$ and $N_1$, ..., $N_\xi$ randomly and choose the remaining message blocks so that $M_i=N_i$, $i=\xi+1, ..., l$. Then, use the trick above to ensure the key for the next round is identical for both messages (i.e. create a collision at stage $\xi$ during the first pass instead of at the beginning). Then, wait for a collision to happen in the 2-nd round at block $\xi$. It happens with probability ${2^{block\_size/2}}$ for a primitive $E$ with block size $block\_size$. This appears to be possible as the first message blocks are randomly chosen.

Case $n>2$. This procedure can be followed up to any round $n$ with complexity $2^{block\_size*{n-1\over2}}$.

Example. With the 3DES as $E$ and an hash output size of 512 bits, this leads to a collision attack for CBC-HASH with 8 rounds that has complexity $2^{32\cdot 7}$ instead of the $2^{32*8}$ of the birthday paradox.

I am more generally concerned about the small "bandwidth" issue due to the use of an underlying CBC with a block cipher of small output size.

-
The problem is that those constructions require a sufficient block size. In practice 256 or 512 bits. I think fgrieu's premise is a block size that's smaller than the desired hash size. | Additionally when you use such a construction with AES, it might expose AES's key schedule weaknesses. – CodesInChaos Oct 11 '12 at 21:38
CodeInChaos is right that my problem with Davies-Meyer and friends is the insufficient block size of available block ciphers; e.g. 128 bit at best in any hardware that I use, which is insufficient for a secure hash using DM. Also, I do not care so much for speed, as one of the application would be a purposely-slow hash, à la scrypt. – fgrieu Oct 12 '12 at 7:03
@CodesInChaos: if you assume AES message processing can be DPA protected, then so can AES key schedule, since they are based on the same primitives. In practice, key schedule is also protected. – bob Oct 12 '12 at 8:30
@bob: If Rijndael ever had 256-bit plaintexts, that was removed in AES. About my rationale: I am often using Smart Cards or HSM platforms where DES (resp. AES) is a fast hardware thing with 64-bit (resp. 128-bit) data input and 64/128/192 (resp. 128/192/256-bit) key input, hardware support for the XOR required by CBC, and extensive hardware DPA protection; it has a formally security-certified API including fast CBC encrypt (and slightly slower decrypt), anything else either is a subset, or is not formally security-certified. – fgrieu Oct 12 '12 at 9:11

1
@fgrieu: you are correct that the case $n>1$ cannot be attacked since the key after first round was the same for both messages and due to the bijectivity of the block cipher, a collision could not occur. I updated the last paragraph accordingly. As I write, I'm concerned about the small "bandwidth", and there is probably a lot to do, but would require some more time. – bob Oct 22 '12 at 9:27
show 1 more comment
{"extraction_info": {"found_math": true, "script_math_tex": 0, "script_math_asciimath": 0, "math_annotations": 0, "math_alttext": 0, "mathml": 0, "mathjax_tag": 0, "mathjax_inline_tex": 105, "mathjax_display_tex": 2, "mathjax_asciimath": 0, "img_math": 0, "codecogs_latex": 0, "wp_latex": 0, "mimetex.cgi": 0, "/images/math/codecogs": 0, "mathtex.cgi": 0}, "config": {"markdown_headings": true, "markdown_code": true, "boilerplate_config": {"ratio_threshold": 0.18, "absolute_threshold": 10, "end_threshold": 15, "enable": true}, "remove_buttons": true, "remove_image_figures": true, "remove_link_clusters": true, "table_config": {"min_rows": 2, "min_cols": 3, "format": "github"}, "remove_chinese": true, "remove_edit_buttons": true, "extract_latex": true}, "english_confidence": 0.9136784076690674, "perplexity_flag": "middle"}