Subject: [IPsec] mot sure if this posted before, so resending

From: Stephen Kent <[email-masked]>
Date: Mon, 06 Apr 2015 15:07:58 -0400

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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 7 Apr 2015 14:21:46 +0300

> On Apr 6, 2015, at 10:07 PM, Stephen Kent <[email-masked]> wrote:
> 
> Yoav,
> 
>> Hi,
>> 
>> 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

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 07 Apr 2015 10:42:18 -0400

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 ad…
works for me.
> 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”
>
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., [email-masked].

Steve