11
$\begingroup$

FIPS 202 defines 2 functions, SHAKE128 and SHAKE256, as extendable-output functions (XOFs) that can have variable output length. But in Appendix A.2 marks:

it is possible to use an XOF as a hash function by selecting a fixed output length. However, XOFs have the potential for generating related outputs—a property that designers of security applications/protocols/systems may not expect of hash functions

Later it describes a theoretical use case (and explicitly discourage such uses):

For example, a naïve (and non-approved) way for two parties to agree to derive a 112-bit Triple DES key from a message designated as keymaterial would be to compute SHAKE128(keymaterial, keylength), where keylength is 112. However, if an attacker is able to induce one of the parties to use a different value for keylength, say 168 bits, but the same value for keymaterial

So what is the use case for these functions? Is there any reasonable use case where these functions should be used instead of standard (fixed-size output functions) SHA-3 functions?

$\endgroup$
  • 1
    $\begingroup$ Welcome to crypto, hauleth, excellent first question. One of those questions everybody is afraid to ask :) Note that personally I think the key derivation is fine. Key derivation is usually deterministic (although the inclusion of a salt is highly recommended, if the protocol allows it). So if the attacker is able to "induce one of the parties to use ... same value for keymaterial" then you are in trouble for any KDF. $\endgroup$ – Maarten - reinstate Monica Nov 16 '15 at 16:57
  • $\begingroup$ Note that the above text does not seem to preclude the use of SHAKE within existing or new and upcoming KDF's - as far as that is possible without major modification. $\endgroup$ – Maarten - reinstate Monica Nov 16 '15 at 17:16
  • $\begingroup$ @MaartenBodewes of course, but I think that if there is some XOF KDF then it should produce completely different output for each length. E.g. SHAKEn should append n to message to make both outputs unrelated. $\endgroup$ – Hauleth Nov 16 '15 at 17:21
  • 2
    $\begingroup$ As an example (although a narrow one), CFRG/IRTF may use (not sure if they have decided yet) SHAKE-256 as the internal hash for the Ed448 signature standard (although they may add a custom padding). $\endgroup$ – SEJPM Nov 16 '15 at 17:25
  • $\begingroup$ @SEJPM I would consider variable length hashes in signature generation an excellent raison d'etre for SHAKE, good one. $\endgroup$ – Maarten - reinstate Monica Nov 16 '15 at 17:27
16
$\begingroup$

As of now I can think of four different applications for XOFs.
Note that some change the padding depending on the requested output size and so the outputs are truly unrelated, Skein does this.

  1. Signature message hashing. Using an XOF you don't have to rely on ad-hoc constructions for hashing the message in signature schemes to the appropriate size. For example, implementing RSA-FDH is trivial with an XOF while it is not so easy with fixed size hashes. As another example the CFRG of the IRTF is currently evaluating using SHAKE-256 as the internal hash function for the Ed448 signature standard (which needs an 912-bit hash internally).
  2. Stream ciphers. This may be a artificial but you can in fact abuse your XOF as a stream cipher if you don't want to trust the well studied AES-CTR or Salsa constructions. This was indeed proposed in the Skein specification.
  3. Key derivation. Assume for a second that you didn't know HKDF. You trivially replace HKDF with an XOF in most scenarios as you could simply save the state after processing the master secret and then pad it with the context for each key-derivation. Or if you only need one giant block of derived bits, you'd need to call HKDF or a fixed size hash many times but your XOF only once.
  4. Easier instantiation of random oracles. Some security proofs rely on the so-called random oracle model to prove the security of a given scheme. Normally you'd use some artificial construction around a fixed-size hash function to get the desired output size, but with XOFs you can just plug them right in without having to fear any mistakes on your side potentially breaking the proofs (most people don't know / understand in many cases, me included).

TL;DR: Native XOFs aren't necessary and can be emulated using known "ad-hoc" constructions, but they are highly convenient in random oracle based schemes, in signature message hashing and for fast and easy key derivation.

$\endgroup$
8
$\begingroup$

NIST has yet to standardize any accepted uses for these functions. As they said in response to a comment on the SHA-3 draft (pdf) which questioned this:

The text in Section 7 on conformance explicitly asserts that approved uses of the extendable-output functions will be specified in NIST special publications. NIST will consider these comments in the development of those publications. Also, text was added to clarify that extendable-output functions are not yet approved as variable-length hash functions.

They are currently considering some of them, however. Here (pdf) is a 2014 workshop presentation on MAC and PRF algorithms for SHA-3, which suggests XMAC and XKDF, which are a MAC and a KDF (duh) based on the XOFs.

The Keccak website has some other other suggestions, too, including the appropriate size hashing for asymmetric algorithms that SEJPM mentions in the other answer:

Concretely, XOFs can be used instead of complex constructions involving hash functions and counters such as MGF1. With RSA, this is of immediate benefit to full domain hashing, to RSA OAEP (Optimal Asymmetric Encryption Padding) and to RSA PSS (Probabilistic Signature Scheme). Other use cases are key derivation functions and stream ciphers.

$\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.