0
$\begingroup$

Blake2(1024 bit state) permutation (compression function core) is basically a modified ChaCha permutation. One of the modifications is to mix in message bits (key schedule?). Given that blake2 is a hash function, designed to resist related messages (related key attack?) would it not also make a good 1024 bit block cipher?

Some of my questions regarding the resultant construction would be:

  1. Will it be a secure block cipher?

  2. Given that the result will be a 1024 block cipher with what appears to be a 1024 bit key (previously, the message block) would you be able to expect a 2^1024 security level? (in practice the key would likely be derived from some PRNG of a lower security level rather than opt for this overkill)

The use case will be to encrypt AD in AEAD. To make AEAD packets(large, not necessarily networking) appear as entirely random bits. AD will also include parameters of encryption for the packet along with a nonce.

$\endgroup$
5
  • 1
    $\begingroup$ What's the motivation? What's wrong with ChaCha20? An easier way to make an AEAD out of a hash function would be to use an XOF like BLAKE3. $\endgroup$ Jul 18, 2022 at 19:44
  • $\begingroup$ The motivation is the last paragraph, for stream ciphers you need to maintain state. For block ciphers in codebook mode (nonce+AD length will be < 128 bytes) you just need a key. I'm asking about a block cipher, expressed no interest in making it into anything else. $\endgroup$ Jul 18, 2022 at 19:51
  • $\begingroup$ Ah, I misread the last paragraph, sorry. However, I'm still a bit confused. You just want to encrypt associated data? You could derive the nonce using a KDF, you could use a fixed nonce as long as you change the key each time, or you could use a nonceless SIV scheme, which again involves changing the key each time. There's no need to roll something new. $\endgroup$ Jul 18, 2022 at 20:06
  • $\begingroup$ I'd rather use Threefish. While it's mainly used as the core of the Skein hash, it's designed to be secure as a tweakable wide blockcipher. $\endgroup$ Jul 19, 2022 at 6:55
  • 2
    $\begingroup$ But in any case, the first thing you should look for is different modes of operations (e.g. SIV), instead of unusual primitives. $\endgroup$ Jul 19, 2022 at 6:57

2 Answers 2

2
$\begingroup$

To answer question 1, we don't know whether that will be a secure construction. Just because the compression function of a hash function is secure when using it as a hash function doesn't mean it's secure when using it as a block cipher. For example, there are attacks on the block ciphers underlying SHA-1 and SHA-2 that wouldn't apply to the hash algorithms themselves.

As an example of a weakness that could theoretically occur, say the first half of the BLAKE2 permutation is found to be weak, but the second half is independent and indistinguishable from random. Then BLAKE2b would likely still be secure, but the permutation as a block cipher probably would not.

In order to determine whether this design is secure, you'd have to conduct normal cryptanalysis on the design, and cryptanalysis on ChaCha would likely not apply because there the permutation is not used as a block cipher. Without sufficient study, I wouldn't recommend this approach.

An approach which is more likely to be secure (but you should also not use because it has seen zero cryptanalysis) is a four-round Feistel cipher with keyed BLAKE2b as the $ F $ function. That would yield a 1024-bit block cipher with a key up to 255 bytes. At least this approach would have a security proof based on some assumptions about keyed BLAKE2b, although it might not be particularly performant.

While speculating about this design is theoretically interesting, I'd encourage you to use a more standard approach which has seen substantial real-world cryptanalysis and is still considered to be secure.

$\endgroup$
1
$\begingroup$

The BLAKE2b keyed permutation is not an ideal cipher. For $2^{64}$ "weak" keys consisting of the same word $k$ repeated $16$ times, it is elementary to distinguish it from a random permutation via the property $$ E\left(k^{16}, m \lll s\right) = E\left(k^{16}, m\right) \lll s\,, $$ where $\lll s$ means rotating the columns of the $4\times 4$ state by $s$, e.g., $$ \pmatrix{a & d & h & m \\ b & e & i & n \\ c & f & j & o \\ d & g & l & p} \lll 1 = \pmatrix{d & h & m & a \\ e & i & n & b \\ f & j & o & c \\ g & l & p & d}\,. $$ This property is exploited in the attacks on modified BLAKE2b with a chosen IV, which alter the initialization constants of BLAKE to make the scheme weaker.

Now, an AEAD typically does not rely on its underlying block cipher to be ideal, but simply a pseudorandom permutation. In this case, the probability of a weak key is negligible ($2^{-960}$), and the standard cryptanalysis of the permutation becomes more relevant.

To my knowledge there is no attack that would compromise the security of the permutation when used with a random key. But then again this is not a setting that has seen much study, so the cryptanalysis may be incomplete. I would not recommend using the BLAKE2b keyed permutation in this manner for anything serious.

$\endgroup$

Your Answer

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

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