13

Consider a block cipher with a key of size 128 bits but a small block size, say 32 bits. Is this kind of block cipher secure?

I would like to know to what extent I can use a small block cipher, like a 32 bit block cipher. What are the constraints so that the use is acceptable in a real life application.

For instance, if we use a one-time key, that is, to encrypt only one message. Besides, the message could be small.

Suppose that when we want so send one file, we perform a key agreement so that we use the key for one message. This scenario is not efficient, but the CPA find-then-guess game is not adequate in this case.

Ilmari Karonen
  • 46,700
  • 5
  • 112
  • 189
Dingo13
  • 2,917
  • 3
  • 29
  • 46

2 Answers2

13

Such a block cipher would be completely unusable in any of the standard modes of operation, presuming you want at least IND-CPA security. Say, for instance, that you are using it in CTR mode. A chosen plain text adversary looking at a cipher text consisting of only two blocks (i.e. 2 times 32 bits), would have a non-negligible probability (higher than $2^{-32}$) of guessing if the cipher text is produced by your block cipher in CTR mode, or a random function.

This matters in so far that a block cipher in CTR mode is only secure up to the bound where the block cipher might still be modeled as a PRF, as defined in the security proof. If you are able to distinguish the block cipher from a PRF, CTR mode is no longer IND-CPA secure. This applies to all other standard modes as well.

If one of the CTR mode cipher texts is 16 GB, you will have revealed the entire code book, and the adversary will not need the key.

If you have a hard time seeing this, consider a 2-bit block cipher in CTR mode that has produced the ciphertext stream 3-1-0. If Eve has tricked us into encrypting 0 three times, then the next CTR value must be 2 with probability 100%. Real plaintexts are nearly that predictable, so exhaustion of the ciphertext space is a practical limit. 32 bits is just too tight.

Edit: Please also note that it would be a mistake to assume that failure to meet IND-CPA security, would only be relevant in scenarios where the exact CPA game can be played out. Suppose, for instance, that you encrypt only a single message (in CTR mode) with each key, and that this message is $l$ bits long. If $l \le 32$ you are safe, but if it is longer, you are not. Suppose $l=64$. In such case the plain text $m$ might be divided into two blocks $m=m_0|m_1$ and the cipher text $c$ into two blocks $c=c_0|c_1$. Now, the attacker might immediately deduce that $m_1\ne m_0\oplus c_0 \oplus c_1$ (because $m_i \oplus c_i = E_k(i)$ and $E_k(0) \ne E_k(1)$) and has learned $32/{2^{32}}=2^{-27}$ bits of information about $m$. The more that is known of patterns in $m$ and the greater the length $l$, the more information about $m$ might be deduced even in a cipher text only attack.

poncho
  • 154,064
  • 12
  • 239
  • 382
Henrick Hellström
  • 10,556
  • 1
  • 32
  • 59
3

As pointed in this other answer, a 32-bit block cipher with 128-bit key can be practically unsafe when used with the standard operating modes. However, it is still fine in some other uses.

For example, we can derive a wide shared secret from the initial 128-bit $K$, say as the concatenation of $E_K(3\cdot i)\oplus E_K(3\cdot i+1)\oplus E_K(3\cdot i+2)$ for $i$ in range $[0\dots(2^{32}-4)/3]$, which is may be [update: I wildly conjecture, without proof or even strong argument, and thus imprudently; see hand-waving attempts of coming with justification in my comments] computationally indistinguishable from a random sequence of $(2^{37}-32)/3$ bits (I use three terms because with just one, all the blocks are different. And with two, the all-zero block can not occur). We can then use the above random sequence in a stream cipher.

fgrieu
  • 149,326
  • 13
  • 324
  • 622