Ben S3 <[email protected]> wrote: > 1) KMAC supports use of customisation strings, and this draft makes use > of them to provide separation between the IKE context and the ESP/AH > context. There seemed to be some interest in the room at IETF 123 for > this approach. The concern is that without use of customisation > strings, the same PRF output could be derived in different contexts.
"could", but there are other things that are different, as you point out.
However, it costs almost nothing, and guards against some possible future
where people have are able to create application-non-specific SHA3 dictionaries.
> 3) We've included the option to use KMAC/SHAKE as an AUTH
> transform. Typically, the preferable thing to do would be to use an
> AEAD algorithm instead of having separate encryption and authentication
> algorithms, but there are some use cases for authenticated
> communication without encryption via ENCR_NULL (or AH, but ENCR_NULL is
> preferred by RFC 8221). RFC 8221 also alludes to IoT use cases where
> AEAD algorithms might be undesirable if they need to track state to
yes, that's correct, also accelerated hardware/instructions do not always
allow all the AEADs, and sometimes slower algoritms cost less power.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
