Using Keccak permutation as a block cipher

Question

The inverse of Keccak is slow, but if you have a problem where that is not a concern would this be a secure cipher? The encryption function can be made incredibly fast in hardware. Or the reverse if you choose to encrypt using the inverse.

Is there any cryptanalysis of block ciphers that are unbalanced in such a fashion? Inverse being more expensive and having different diffusion properties.

The round constant step (used to break symmetry) in the round function is the only thing that needs to be changed to employ a key schedule.

The nonlinear step is worrisome, they use a simple cellular automaton rule: flip bit if pattern 01 is to its right (and wrap around). This makes invertability cumbersome for an arbitrary odd length input (not possible for even length), but they use it for just a 5 bit input which just makes it a trivial 2^5 S-box - is it a good one? 0* maps to 0* and 1* to 1* for example.

PS: * means repetition, in the case of keccak 1* = 11111

Answer 1

First, this is a slightly silly exercise because most applications are not well-served by a block cipher in particular but rather by things built out of them, such as authenticated encryption schemes. Probably the most widely used authenticated encryption scheme today built out of AES, AES-GCM, doesn't even use the inverse direction, and would provide better security bounds if AES were a pseudorandom function family rather than a pseudorandom permutation family. And there are already perfectly good authenticated encryption schemes built out of Keccak, such as Ketje and Keyak, both submitted to CAESAR.

But let's take the exercise at face value and suppose you really do want a block cipher. The obvious way to get a block cipher out of Keccak is with a single-key Even–Mansour construction analyzed by Dunkelman, Keller, and Shamir. Specifically, for a $b$-bit permutation $F$ (standard SHA-3 has $b = 1600$, but there are shorter variants, such as $b = 200$ used by Ketje for environments with tight resource constraints), we can define, for $b$-bit keys $k$, the $b$-bit block cipher $$E_k(m) = F(m \oplus k) \oplus k.$$ Since collision-resistance is not relevant to this application, instead of the standard $\operatorname{Keccak-\mathit{f}}[b] = \operatorname{Keccak-\mathit{p}}[b, n_r]$ permutation where $n_r = 12 + 2\log_2 (b/25)$ is the standard number of rounds, we might consider a much smaller number $n_r$ of rounds, as you will find Ketje and Keyak use.

Maybe a 1600-bit key seems excessive for a standard 128-bit security level. Maybe you could make do with a smaller key, padding it with zeros, $$E_k(m) = F(m \oplus (k \mathbin\Vert 0^{b - 256})) \oplus (k \mathbin\Vert 0^{b - 256}).$$ I haven't done the analysis of a padded-key variant of Even–Mansour; maybe if you read the Dunkelman, Keller, and Shamir paper you'll find an obvious answer. But we can always derive longer keys from shorter keys using standard functions like HKDF, or even Keccak-based ones like SHAKE256 or KMAC. So unless you have an amazingly constrained application requiring (a) squeezing out those last few cycles, and (b) a novel Keccak-based block cipher, those cycles are probably not worth the effort to figure out the detailed security analysis! Thus I leave it as an extra-credit exercise for the reader which will not affect your standard grade.