> On Apr 6, 2015, at 10:07 PM, Stephen Kent <k...@bbn.com> wrote:
>
> 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.
>
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.
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? 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?
Yoav
[1] http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
