Return to Answer

Before we start answering the subquestions, let's bring up some background knowledge.

The sponge construct was first proposed by the Keccak team as a bridging element in a security proof for the older RadioGatún hash function. On their web page, they describe it as generalization of both hash function (var->fix) and stream cipher (fix->var).

Since SHAKE-128/256 are directly based on sponge constructs, we'll just assume for now the authors intended XOF as the generic term for their trademark product Sponge.

type                input                  output
stream cipher       fixed-length key       variable-length key-stream
xof                 variable-length data   variable-length data
hash function       variable-length data   fixed-length digest

So the question 1 can be answered as follow: No, that'd violate the definition of XOF.

And question 2: No. They're stream ciphers, two of which uses the counter construct.

If you search "cryptographic seed-expander" on Bing in 2018-02, then the first few results unrelated to Crypto.SE is the NIST page for post-quantum cryptography. The story goes like this:

Back in the earily days of preparing for the contest, NIST errornously intended that submitters obtain randomness source for their keygen-signing-encrypt functions using libc rand(). This was met with protest by notable participants on the official mailing list.

After discussion, it was decided there would be separate randomness calls for 1.) generating small amount of keying material sufficient for given security level, and for 2.) expanding keying material to longer bitstring from which mathematical objects can be extracted.

The latter had since been called "seed expander" in official NIST documents, which roughly corresponds to DRBG.

So the question 3 can be answered as follow: It does what a DRBG/PRNG does. The interface of a DRBG applies.

I'd like to answer question 4 as follow: It doesn't make sense comparing them because their purpose are different. And this difference in purpose makes their programming interface different as well. For example, the typical interface for a XOF function is much simpler than a DRBG, and has much less parameters to tune than KDF.

Before we start answering the subquestions, let's bring up some background knowledge.

The sponge construct was first proposed by the Keccak team as a bridging element in a security proof for the older RadioGatún hash function. On their web page, they describe it as a generalization of both hash function (var->fix) and stream cipher (fix->var).

Since SHAKE-128/256 are directly based on sponge constructs, we'll just assume for now that the authors intended XOF as the generic term for their trademark product Sponge.

type                input                  output
stream cipher       fixed-length key       variable-length key-stream
xof                 variable-length data   variable-length data
hash function       variable-length data   fixed-length digest

So question 1 can be answered as follows: no, that would violate the definition of XOF.

And question 2: no. They're stream ciphers, two of which use the counter construct.

If you search "cryptographic seed-expander" on Bing in 2018-02, then the first few results unrelated to Crypto.SE refer to the NIST page for post-quantum cryptography. The story goes like this:

Back in the early days of preparing for the contest, NIST specified that submitters obtain randomness source for their keygen-signing-encrypt functions using libc rand(). This was correctly met with protest by notable participants on the official mailing list.

After discussion, it was decided there would be separate randomness calls for 1.) generating small amounts of keying material sufficient for a given security level, and for 2.) expanding keying material into a longer bitstring from which mathematical objects could be extracted.

The latter has since been called "seed expander" in official NIST documents, which roughly corresponds to DRBG.

So question 3 can be answered as follows: It does what a DRBG/PRNG does. The interface of a DRBG applies.

I'd like to answer question 4 as follows: It doesn't make sense to compare them, because their purposes are different. And this difference in purpose makes their programming interface different as well. For example, the typical interface for a XOF function is much simpler than that for a DRBG, and has many fewer parameters to tune than KDF.

Before we start answering the subquestions, let's bring up some background knowledge.

The sponge construct was first proposed by the Keccak team as a bridging element in a security proof for the older RadioGatún hash function. On their web page, they describe it as generalization of both hash function (var->fix) and stream cipher (fix->var).

Since SHAKE-128/256 are directly based on sponge constructs, we'll just assume for now the authors intended XOF as the generic term for their trademark product Sponge.

type                input                  output
stream cipher       fixed-length key       variable-length key-stream
xof                 variable-length data   variable-length data
hash function       variable-length data   fixed-length digest

So the question 1 can be answered as follow: No, that'd violate the definition of XOF.

And question 2: No. They're stream ciphers, two of which uses the counter construct.

** More on question 3 & 4 later after a bit of research.

If you search "cryptographic seed-expander" on Bing in 2018-02, then the first few results unrelated to Crypto.SE is the NIST page for post-quantum cryptography. The story goes like this:

Back in the earily days of preparing for the contest, NIST errornously intended that submitters obtain randomness source for their keygen-signing-encrypt functions using libc rand(). This was met with protest by notable participants on the official mailing list.

After discussion, it was decided there would be separate randomness calls for 1.) generating small amount of keying material sufficient for given security level, and for 2.) expanding keying material to longer bitstring from which mathematical objects can be extracted.

The latter had since been called "seed expander" in official NIST documents, which roughly corresponds to DRBG.

So the question 3 can be answered as follow: It does what a DRBG/PRNG does. The interface of a DRBG applies.

** An additional question 5 is intended to be asked and answered in the answer: When expanding fixed/variable-length key material, should I use xof or stream cipher / xof or hash function + stream cipher?

Before we start answering the subquestions, let's bring up some background knowledge.

The sponge construct was first proposed by the Keccak team as a bridging element in a security proof for the older RadioGatún hash function. On their web page, they describe it as generalization of both hash function (var->fix) and stream cipher (fix->var).

Since SHAKE-128/256 are directly based on sponge constructs, we'll just assume for now the authors intended XOF as the generic term for their trademark product Sponge.

type                input                  output
stream cipher       fixed-length key       variable-length key-stream
xof                 variable-length data   variable-length data
hash function       variable-length data   fixed-length digest

So the question 1 can be answered as follow: No, that'd violate the definition of XOF.

And question 2: No. They're stream ciphers, two of which uses the counter construct.

If you search "cryptographic seed-expander" on Bing in 2018-02, then the first few results unrelated to Crypto.SE is the NIST page for post-quantum cryptography. The story goes like this:

Back in the earily days of preparing for the contest, NIST errornously intended that submitters obtain randomness source for their keygen-signing-encrypt functions using libc rand(). This was met with protest by notable participants on the official mailing list.

After discussion, it was decided there would be separate randomness calls for 1.) generating small amount of keying material sufficient for given security level, and for 2.) expanding keying material to longer bitstring from which mathematical objects can be extracted.

The latter had since been called "seed expander" in official NIST documents, which roughly corresponds to DRBG.

So the question 3 can be answered as follow: It does what a DRBG/PRNG does. The interface of a DRBG applies.

I'd like to answer question 4 as follow: It doesn't make sense comparing them because their purpose are different. And this difference in purpose makes their programming interface different as well. For example, the typical interface for a XOF function is much simpler than a DRBG, and has much less parameters to tune than KDF.

Before we start answering the subquestions, let's bring up some background knowledge.

The sponge construct was first proposed by the Keccak team as a bridging element in a security proof for the older RadioGatún hash function. On their web page, they describe it as generalization of both hash function (var->fix) and stream cipher (fix->var).

Since SHAKE-128/256 are directly based on sponge constructs, we'll just assume for now the authors intended Sponge as their trademark for the generic term XOF.

type                input                  output
stream cipher       fixed-length key       variable-length key-stream
xof                 variable-length data   variable-length data
hash function       variable-length data   fixed-length digest

So the question 1 can be answered as follow: No, that'd violate the definition of XOF.

And question 2: No. They're stream ciphers, two of which uses the counter construct.

** More on question 3 & 4 later after a bit of research.

** An additional question 5 is intended to be asked and answered in the answer: When expanding fixed/variable-length key material, should I use xof or stream cipher / xof or hash function + stream cipher?

Before we start answering the subquestions, let's bring up some background knowledge.

The sponge construct was first proposed by the Keccak team as a bridging element in a security proof for the older RadioGatún hash function. On their web page, they describe it as generalization of both hash function (var->fix) and stream cipher (fix->var).

Since SHAKE-128/256 are directly based on sponge constructs, we'll just assume for now the authors intended XOF as the generic term for their trademark product Sponge.

type                input                  output
stream cipher       fixed-length key       variable-length key-stream
xof                 variable-length data   variable-length data
hash function       variable-length data   fixed-length digest

So the question 1 can be answered as follow: No, that'd violate the definition of XOF.

And question 2: No. They're stream ciphers, two of which uses the counter construct.

** More on question 3 & 4 later after a bit of research.

If you search "cryptographic seed-expander" on Bing in 2018-02, then the first few results unrelated to Crypto.SE is the NIST page for post-quantum cryptography. The story goes like this:

Back in the earily days of preparing for the contest, NIST errornously intended that submitters obtain randomness source for their keygen-signing-encrypt functions using libc rand(). This was met with protest by notable participants on the official mailing list.

After discussion, it was decided there would be separate randomness calls for 1.) generating small amount of keying material sufficient for given security level, and for 2.) expanding keying material to longer bitstring from which mathematical objects can be extracted.

The latter had since been called "seed expander" in official NIST documents, which roughly corresponds to DRBG.

So the question 3 can be answered as follow: It does what a DRBG/PRNG does. The interface of a DRBG applies.

** An additional question 5 is intended to be asked and answered in the answer: When expanding fixed/variable-length key material, should I use xof or stream cipher / xof or hash function + stream cipher?