BLAKE3 for Block and Stream ciphers?

Question

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?

Answer 1

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.