Yoav,
I think it’s risky to base decisions on our attempts to divine future NIST
decisions, but I agree that out best option now is to leave the 64-bit IV (or
nonce) explicit for now and perhaps later add an IKE extension that allows you
to “compress” the IV as long as it’s equal to the packet counter. That allows
the ESP implementation to compress the ESP packet as long as the encryption
module keeps generating payloads that have an IV exactly the same as the packet
counter.
works for me.
I’ve recently had the dubious pleasure of going over some NIST document ([1]).
Appendix A.5 is about Key/IV pair uniqueness in AES-GCM, but I guess (divining
again…) that if they ever accept ChaCha20, they might ask for similar things.
So what does it say about IV generation?
There are several ways to generate the IV. One is to generate the IV in
compliance with the TLS 1.2 GCM
Cipher Suites for TLS, as described in the corresponding IETF RFC 5116
and 5288. Alternatively, the IV may
be generated randomly or set deterministically, possibly by being
incremented by 1 every time a new value
is needed.
That sounds good, because “deterministically… by being incremented by 1 every
time” is exactly what we’re looking for, right?
seems reasonable to me.
The document goes on to say that the method in RFC 5288 is allowed only for TLS
1.2, and “in all other cases the following requirements shall be satisfied”
If the GCM Key is generated either internally or externally and the IV
is generated internally
deterministically then the requirement of SP 800-38D quoted in the
Background section above will be
modified. Instead of requiring that the probability of any (key, IV)
collision anywhere in the
Universe at all times did not exceed 2^-32, it will only be required
that for a given key distributed to
one or more cryptographic modules, the (key, IV) collision probability
would not exceed 2^-32. This
is equivalent to the requirement that for any key distributed to one or
more modules the probability of
a collision between the deterministically-generated IVs is no greater
than 2^-32.
That is still fine, because a 64-bit counter has a zero chance of repeating, and 0
< 2^-32. But then the document goes on to “specify what the module has to do to
meet this requirement”.
Each deterministically established IV shall include an encoding of the
module’s name and the
name shall be long enough to allow for at least 2^32 different names.
For example, if the module’s
name is such that it consists of at least 8 hexadecimal characters then
this condition is satisfied,
since 16^8 is no smaller than (indeed, equal to) 2^32 . Alternatively,
if the name consists of at least
6 alphanumerical characters, each having at least 62 values, then this
is also sufficient. Even
though not all possible names are equally likely to be used, just the
fact that the modules can
possibly have at least 232 different names will be sufficient to meet
this requirement.
So now we’re supposed to dedicate 32 bits of the available 64 to encoding the
module name??? That leaves 32 bits per key for packet counter. That also means
that ESN is a superfluous feature, because if you go above 2^32 packets per SA,
the pigeonhole principle applies.
Does anyone know the method behind this madness?
I think the module name requirement is intended to accommodate
multi-sender, same key, scenarios,
but you should direct the question to NIST, e.g., lily.c...@nist.gov.
Steve
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
