1
$\begingroup$

When assuming the following idea for ciphers:

For a block cipher, a 4-round balanced Feistel network where the PRF is BLAKE3 and the key schedule is: input key, input key with every odd bit flipped, input key with every even bit flipped, input key with every bit flipped.

For a stream cipher: a 64-bit unsigned int that gets concatenated with the key and hashed for each block of keystream, rounded to the nearest multiple that fits and the excess bytes trimmed off, then xor the keystream with the plaintext.

It just seems to me like these would be competitive with hardware-accelerated AES and ChaCha20, with the added benefit of being able to use quite large keys, in particular for a block cipher for disk encryption, where you could make a really large cipher and fit both the actual encryption key and block number into the key without the need for a tweak, and encrypt/decrypt more data in one go.

Beyond the risk of shoddy implementation is there any inherent risk in constructions like these? If we have a really good hash that's also fast, is there a point in even designing dedicated block and stream ciphers from the ground up?

$\endgroup$
4
  • $\begingroup$ Blake3 github.com/oconnor663/bao $\endgroup$
    – kelalaka
    Commented Mar 12 at 19:42
  • 1
    $\begingroup$ Even in ideal case, using prfs, 4 rounds is not enough. Further, one has to account for imperfections in blake3. Finally, whatever primitive is built might require SPRP security, increasing the round count further. So I don’t see how to get away with less than 10 rounds. Also, the key schedule with bit flipping, makes the existing analysis invalid. It might still have some good properties but I wouldn’t « use » this construction. $\endgroup$ Commented Mar 13 at 0:40
  • 1
    $\begingroup$ Separate angle: why would you use BLAKE3, a hash function, for a block cipher that gets turned into stream cipher? Wouldn't it be simpler (and possibly faster) to just use ChaCha8 as a stream cipher? $\endgroup$
    – rozbb
    Commented Mar 14 at 4:50
  • $\begingroup$ There are also already proposals for BLAKE3-based AEADs by one of the BLAKE3 authors, namely Bessie and BLAKE3-AEAD. $\endgroup$ Commented Apr 7 at 10:50

1 Answer 1

1
$\begingroup$

Let's start with the stream cipher idea, since it's the simplest one. BLAKE3 already supports arbitrary-length outputs, so when you key it it can be trivially used as a stream cipher by hashing an arbitrary-sized nonce and producing whatever amount of output is necessary. The security of this stream cipher reduces to the PRF security of the keyed BLAKE3 compression function. The performance here should be roughly comparable to Chacha14.

You can build a block cipher out of the BLAKE3 compression function as well. Indeed, 4 Feistel rounds are sufficient to obtain an advantange of at most $\frac{q^2}{2^{n}} + \frac{q^2}{2^{2n}}$, $n=256$, for an attacker making $q$ (adaptive chosen-ciphertext) queries to the block cipher. However, such security reductions typically require independent round keys, and your proposal's subkeys are definitely not independent.

It is possible to only use one round key by using an idea by Patarin, and developed further by Nandi: $$ \begin{align} L_1, R_1 &= R_0, L_0 \oplus \xi\left(\mathrm{F}(K, R_0)\right) \\ L_2, R_2 &= R_1, L_1 \oplus \mathrm{F}(K, R_1) \\ L_3, R_3 &= R_2, L_2 \oplus \mathrm{F}(K, R_2) \\ L_4, R_4 &= R_3, L_3 \oplus \mathrm{F}(K, R_3) \\ \end{align} $$ where $\xi(\cdot)$ is an orthomorphism, i.e., both $\xi(x)$ and $\xi(x)\oplus x$ are bijective. A simple orthomorphism can be the 1-round Feistel round with the identity function: $$ \xi(a,b) = (b, a\oplus b)\,, $$ where $a, b$ are the two 128-bit halves of the output of $F$. Nandi shows that this construction has adaptive chosen-ciphertext advantage of at most $\frac{14q^2}{2^n-1} + \frac{q^2}{2^{2n}}$ which, while a small constant factor worse than independently keyed Feistel, has the convenience of avoiding the issue of devising a key schedule.

Of course, this does not explain why you are building a block cipher out of BLAKE3. In effect this requires 4 BLAKE3 invocations, or 28 rounds for each 512-bit block. This is unlikely to be the most efficient way to build a block cipher, and it's also possible that a fixed-length block cipher is not what you want to begin with.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.