Yoav,
Hi,
There is two questions I would like guidance from the group about.
First is the nonce/IV question: In the current draft, there is a
64-bit IV with guidance not to repeat them (so use a counter or LFSR).
The function itself accepts a 96-bit input nonce, so the nonce is
constructed from the 64-bit IV and 32 zero bits. The reason for doing
this is so the algorithm could be used in a multi-sender case such as
GDOI, where the 32-bit zero can be replaced by a sender ID.
Alternatively, we could generate a 32-bit salt value from the key
material, but I don’t see a reason why we’d want that. Another thing
we could do is what some people are advocating for TLS: Since a
counter is a fine IV (no need for secrecy), we don’t need a 64-bit IV
that has the exact same value as the replay counter. We might as well
save 8 bytes per packet and just feed the replay counter to the
function. The argument against this is that some crypto modules may
have the API set up in such a way that the IVs are generated within
the module and could be something other than a counter (like an LFSR).
The proposal will break such APIs.
agreed. The other, related issue, is that if one wants to achieve FIPS
certification
for an alg like this, the nonce/IV needs to be within the eval boundary
for the
alg certification. I realize that ChaCha is not a FIPS alg, but I recall
someone
asking NIST if it might be willing to evaluate ChaCha. If the goal is
(eventual)
FIPS evaluation, then it makes sense to consider the implications of
trying to reuse the
ESP sequence counter as an input to the IV/nonce in this context.
Steve
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
