update hash to match new gimli spec

[chrisnc]

The Gimli hash candidate in the NIST Lightweight Cryptography Project pads the state differently than the reference code in the original 2017 paper does. It XORs 0x01 into the byte following the last incomplete block, and XORs 0x01 into the last byte of the state (not the 16th byte).

Is there a plan to update libhydrogen to match the new specification?

[jedisct1]

Hi Chris,

libhydrogen uses the KMAC construction. It doesn’t use the Gimli mode as its specification was not finalized, probably still isn’t, and doesn’t bring much over KMAC.

[chrisnc]

I thought the KMAC part was a higher-level construction that is instantiated with a given hash implementation, and in this case the hash implementation changed. I think the change to hydrogen would be to modify gimli_pad_u8 to be the following:

static inline void
gimli_pad_u8(uint8_t buf[gimli_BLOCKBYTES], size_t pos, uint8_t domain)
{
    buf[pos] ^= (domain << 1) | 1;
    buf[gimli_BLOCKBYTES - 1] ^= 0x01;
}

The original reference code uses 0x1f for the buf[pos] but now just uses 0x01 (equivalent to changing the XOF domain tag from 0xf to 0x0). If/when Gimli is finalized is this a change that would be considered? I'm not sure the implications of modifying buf[47] vs buf[15].

[jedisct1]

Gimli hash is not exposed in the public API. Unless other libraries use it within KMAC, which is very unlikely, libhydrogen's hash API is only compatible with itself. Changing the internal hash function is not going to improve this. It would only make it incompatible with itself. I don't think it's worth it.