0

Encrypting values with AES we only need about $2^{64}$ trials until we finding an already used value (some collision). This can be done these days with easy.

To make this harder can we combine two AES to a block cipher $BC_{192}$ with $192$bit in- and output?
E.g. Given $AES_1$ with $k_1$ and $AES_2$ with key $k_2$ (both in ECB mode) and a 192-input value $v$ separated into 6 32-bit chunks (= 192 bit).
$v_i$ means the $i$'th chunk. $v_{1234}$ means a concatenation of those chunks. Same for cipher $c$. Concatenation of both would be $c_iv_j$.

$BC_{192}$ encryption something like: $$AES_1(v_{1234},k_1) = c_{1234}$$ $$AES_2(c_{34}v_{56},k_2) = c'_{34}c_{56}$$ $$AES_1(c_{1256},k_1) = c'_{1256}$$ $$AES_2(c'_{1256},k_2) = c''_{1256}$$ $$AES_1(c''_{12}c'_{34},k_1) = c'''_{12}c''_{34}$$ $$AES_2(c''_{34}c''_{56},k_2) = c'''_{34}c'''_{56}$$ $$v \rightarrow c'''_{123456}$$

Decryption would be inverse of this.

Q: Would this make collision finding harder? In best case about $2^{96}$. Is there any better/faster way without modifying the inner structure of AES?

Similar to some hashes using block cipher we could modify the keys like they do. E.g. with $c'_{34}$ at the mid part. Would that be better? $$AES_1(c_{1256},f(k_1,c'_{34})) = c'_{1256}$$ $$AES_2(c'_{1256},f(k_2,c'_{34})) = c''_{1256}$$

The adversary who wants to find a collision does know all runtime variables. This is also similar to hash function computation which also aim to reduce the collision chance. Other than for those also an inverse function (decryption) like in normal block cipher should exist. It need to be format perceiving as well.
Q2 Do such collision resistant functions have a special name in cryptography? Are there any 192-bit alternatives (or similar, up to 208 bit)?

J. Doe
  • 573
  • 4
  • 15
  • Can you clarify what you mean by "an already used value (some collision)"? With a fixed key $k$, AES$(k,m)$ is a bijection, so it has no collisions. Generally, what kind of collisions do you want to avoid? – Sam Jaques Jun 13 '22 at 14:59
  • @SamJaques Person $A$ and $B$ applying the $N$-bit block cipher (with equal key) to different input values. $A$ in forward direction (encryption). $B$ in backward direction (decryption). In mean it takes about $O(2^{N/2})$ trials until a resulting value is part of the set the other person already tested (in other direction). For a block size of 128 bit this will happen too fast ($\approx 2^{64}$ trials). With a block cipher with 192-bit it would be $2^{96}$ which matches the target security (200 bit block size would be perfect). – J. Doe Jun 13 '22 at 20:09
  • 192-bit is not a very common size among block cipher (in commonly used implementations like crypto++). So I would like to use an existing one and combine them to a 192 block cipher. – J. Doe Jun 13 '22 at 20:09
  • I'm not sure what attack you're trying to avoid. If $A$ and $B$ both know the key, then they have no security guarantees against each other. If someone else, $C$, who doesn't know the key looks at what $A$ and $B$ are doing, a collision just provides $C$ with a plaintext-ciphertext pair, but AES is already supposed to be secure against this. In any case, why not use AES-192 directly? – Sam Jaques Jun 14 '22 at 08:15
  • @SamJaques AES-192 also only using a 128 block size. Rijndael does support a 192 bit block size but haven't found any commonly used - and with this trusted to be secure and fast implementation of it (also with a can-be-used-for-anything licence). – J. Doe Jun 14 '22 at 18:57
  • @SamJaques Other than normal block cipher usage I would like to encrypt some path from one number to another number. If the path is known it should be easy to compute. The path can be separated in multiple steps (e.g. applying a block cipher). Finding a possible step should be computable for a normal PC in not much more than some hours. But (given a start and end value) finding a correct step of the correct path should be as hard as possible. More about it here – J. Doe Jun 14 '22 at 18:57

0 Answers0