Security implications of using larger output length for extendable output functions (XOF)

Question

Could someone explain the security implication of using XOF functions for larger output length? I have seen a few algorithms using fixed 32 bytes output length for SHAKE256. Does this have anything to do with the security strength of the algorithm? Does it mean that its recommended to use 16 bytes output length for SHAKE128?

From my understanding XOF by its nature support larger output length so I could use it for output length of 64, 128 or even infinite bytes. I can feel that it would not be ideal and that using more output length would reduce the security but I cannot pin point why or how except the part where session duration would be longer.

For example, If we consider the kex algorithm for ML-KEM, it has a fixed output length of 32 bytes for the final key in its KDF and if I need more I would need to initiate another round of kex for another 32 bytes.

What would it mean if I instead used an output length of 64 bytes instead? Is it equivalent to using the same keys twice?

What exactly does a security strength of an algorithm mean in this context. Does it guarantee 256 bit security no matter the output length? Does it decrease with increase in the output length?

Sorry for framing the question this way, I do not have a math background and would appreciate if someone explained it in a bit more detail. Thanks.

Answer 1

Could someone explain the security implication of using XOF functions for larger output length?

FIPS 202, the SHA-3 standard, answers this question in Appendix A:

Function	Output Size	Collision	Preimage	2n$d$ Preimage
SHAKE128	$d$	min($d$/2, 128)	≥ min($d$, 128)	min($d$, 128)
SHAKE256	$d$	min($d$/2, 256)	≥ min($d$, 256)	min($d$, 256)

In other words, SHAKE128 provides a 128-bit security level and SHAKE256 provides a 256-bit security level assuming a long enough output. With short outputs, they provide less security than this. With long outputs, the security level is generally capped at 128 or 256 bits (rather than getting worse).

However, they note that if $d > r + c/2$, where $r$ is the rate and $c$ is the capacity of the sponge construction, SHAKE128 and SHAKE256 provide more than 128 and 256 bits of preimage resistance respectively. In fact, if $d > 1600$, a preimage probably doesn't exist. Not that this additional security is practically meaningful.

I have seen a few algorithms using fixed 32 bytes output length for SHAKE256. Does this have anything to do with the security strength of the algorithm? Does it mean that its recommended to use 16 bytes output length for SHAKE128?

A 256-bit output with SHAKE256 offers an equivalent security level to SHA-256.

A 128-bit output with SHAKE128 only offers 64-bit collision resistance, which isn't really collision resistant at all, meaning a weaker security level than all the SHA-2 functions.

If you want the maximum collision resistance, which you should with SHAKE128 especially, you need to use a 256-bit+ output with SHAKE128 and a 512-bit+ output with SHAKE256.

What would it mean if I instead used an output length of 64 bytes instead? Is it equivalent to using the same keys twice?

Now I don't understand this part of your question, but something to consider with XOFs is that changing the output length doesn't affect part of the output. For example, if you use the BLAKE3 demo with a 32-byte output and a 64-byte output, you'll see that the first half is the same in both:

Input (UTF-8): test
Output (32 bytes): 4878ca0425c739fa427f7eda20fe845f6b2e46ba5fe2a14df5b1e32f50603215
Output (64 bytes): 4878ca0425c739fa427f7eda20fe845f6b2e46ba5fe2a14df5b1e32f50603215c82f77a5bd07f7048a95a699e056d0e32bd2bdadc37ee096719c3d9ec12f29a6

They're like most KDFs rather than hash functions unless you include the message length in the XOF input. If you're not careful, these related outputs can cause problems, which is why domain separation is important (like a KDF info parameter).