Simple encoding for customization strings in ASCON-XOF

[Rhys Weatherley]

The discussion of customization strings got me thinking.

When hashing with either ASCON-HASH or ASCON-XOF, the first block is pre-formatted with 8 bytes of IV / domain separation material, including the desired output length in bits. The other 32 bytes are currently set to zero.  The permutation is applied and then absorbing begins.  This first permutation invocation can be pre-computed if the output length is known at compile time.

This leaves 32 bytes that could be used for algorithm names (e.g. "KMAC" or "KDF" or "TupleHash" or whatever) and/or customisation strings.  If the customisation data is too large for a single block, then the permutation can be iterated to absorb the remaining bytes with a domain separation bit set to distinguish customisation data from regular data.

Here is a pseudocode outline of one possible encoding with the algorithm name in the first block and the customisation string absorbed separately:

IF len(AlgorithmName) > 32 THEN

    AlgorithmName = ASCON-HASH(AlgorithmName)

ENDIF

FirstBlock = {8-byte IV} || pad-with-zeroes(AlgorithmName, 32)

S = ASCON_p(FirstBlock)

IF len(CustomString) > 0 THEN

    C = pad-to-rate(CustomString || 1 || zeroes)

    absorb C into S in rate-sized chunks, with the domain separation bit XOR'ed with 1 in each chunk

ENDIF

absorb the input data into S

squeeze the output data from S

An empty algorithm name and customisation string would be equivalent to the current behaviour.

Cheers,

Rhys.