Dear Ben, Adam, and Jonathan,
Dear all,
Thank you for the updated draft draft-ietf-ipsecme-sha3-01. After reading it,
we would like to make the following general comments. One underlying point we
are trying to make is that there is no need to use a mixture of SHA-3, SHAKE
and KMAC, when in fact SHAKE128 and SHAKE256 are XOFs and therefore can act as
a hash function or a PRF. Similarly, for comment 3, KT128 and KT256 can address
all use cases.
In more details:
1. Using KMAC is fine, but it first pads the key to a complete block. This is
not a big deal for long messages, but if short messages are frequent, another
option would be to use SHAKE directly, with the key and the input reversibly
concatenated. Both options are equally fine in terms of security.
For instance, we could do SHAKE(encode(key length) || key || input), where
encode(x) encodes x on {1, 4, 8} byte(s), depending on the alignment we wish to
keep. Alternatively, one could put the key at the end, SHAKE(input || key ||
encode(key length)), to make it friendlier to protections against side-channel
attacks. Or even SHAKE(input || zeroes || key || encode(key length) ||
encode(length of zeroes)), where the number of zeroes is deterministically
computed from the input length to make sure that the key is well aligned.
These options are for discussions here, but we suggest choosing only one for
the document.
2. Section 11 and Table 7 mention both the SHA-3 hash functions and the SHAKE
XOFs. Although there is no problem, we do not see the point of proposing the
SHA-3 hash functions anymore. The SHAKE functions perform better and can do at
least as much as SHA-3.
3. Alongside KMAC/SHAKE, we would suggest allowing the use of functions in RFC
9861 and take advantage of their superior performance. On this topic, we
distinguish between the keyed (PRF, prf+ and integrity protection, Sections 9
and 10) and the unkeyed cases (hashing, Section 11). In both cases, it seems to
us that a solution based on KangarooTwelve works well.
* For the keyed cases, we can imagine a few options:
a) HopMAC: It works great if the inputs are large, as it allows to use
parallelism, and it is also side-channel protection friendly. However, we are
not sure if this last feature matters much here. For this, HopMAC needs 2
passes, which is generally fine but which makes it less efficient if many short
messages are to be processed.
b) KangarooTwelve with the key and the input reversibly concatenated as the
message input. This would be the best option in our opinion, as it allows
parallelism and does only 1 pass as long as the input is less than 8 kilobytes.
c) TurboSHAKE with the key and the input reversibly concatenated as the message
input. This would be similar to option b) but without the parallelism for long
messages.
Domain separation is easy, using the customization string for a) and b) or the
domain separation byte for c).
* For the hashing cases, we think that KangarooTwelve is better than TurboSHAKE
overall, so this makes the discussion easier.
4. In addition to the applications mentioned in the draft, it would be useful
to define a mode for producing long outputs in a parallelized way. Should the
need arise, this would allow efficient SIMD implementations. For instance, one
approach could be as follows:
H ← KT128(input, customization)
output ← TurboSHAKE128(H || counter) concatenated with running counter=0, 1, ...
What do you think? What would be your preferences?
Kind regards,
Benoît, Gilles, Joan, Quynh
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
