7
$\begingroup$

Suppose that SHAKE is seeded with key concatenated to an IV, will the 'key' stream produced by SHAKE128 vulnerable to related key attacks like RC4 is?

My guess is no because seed is already "absorbed" before the key stream is "squeezed" out.

$\endgroup$
  • $\begingroup$ it is highly unlikely there will any kind of related key attack on any SHA3 functions because of the high round count $\endgroup$ – Richie Frame Aug 17 '16 at 11:10
  • $\begingroup$ @RichieFrame high round count is not much of an argument, IMO. You can change the round count by changing what the definition of a round is (cf. BLAKE2 vs. ChaCha round functions). $\endgroup$ – otus Aug 26 '16 at 9:37
  • $\begingroup$ @otus SHAKE128 has a fixed round count, and a fixed round design, it has Keccak-F at its core, and the round count is enough for a hash function, which is much more than required for a stream cipher $\endgroup$ – Richie Frame Aug 26 '16 at 10:26
  • $\begingroup$ @RichieFrame, yes, my point was just that round count is not a very good proxy for overall complexity/mixing, which is what matters here. $\endgroup$ – otus Aug 28 '16 at 5:11
1
$\begingroup$

There is no way to know for sure, but it seems unlikely to me.

SHAKE128 is an extendable output function, basically a hash function with variable output. It must be secure with completely attacker controlled input. If you use it to build a stream cipher (perhaps using KMAC (draft pdf), which is supposed to be PRF), it seems unlikely that related keys would be a concern without the hash function use case also being broken.

However, the security goals of hash functions and stream ciphers are different and SHA-3 itself could be broken, so only time will tell.

My guess is no because seed is already "absorbed" before the key stream is "squeezed" out.

This particular argument does not really make sense, since RC4 also absorbs the key first and only then produces output. Yet it is vulnerable to related key attacks.

$\endgroup$
  • $\begingroup$ The absorb of SHAKE and RC4 are a bit different I think, the former is based on one that's used in a hash function, while RC4 isn't. Correct me if I'm wrong. $\endgroup$ – DannyNiu Aug 27 '16 at 3:20
  • $\begingroup$ @DannyNiu, that's right. The fact that the former derives from a hash function is what made me say it is unlikely. $\endgroup$ – otus Aug 28 '16 at 5:11
1
$\begingroup$

No.

The underlaying permutation is well-analyzed so far as of 2018. It provides good avalanche effect even with single-bit difference; the sponge mode of operation is very well designed. In contrast, RC4 has several demonstrated weakness.

Furthermore, there had authenticated encryption proposal based on Keccak.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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