Re: [Cfrg] How to handle block counter wrap in IETF's ChaCha algorithm?

Hi

For a little context, if you are using straight ChaCha20 as a cipher, the initial block counter should always be zero. This is true both for Bernstein’s original version (with a 64/64 split of block counter/nonce) and with the RFC 8439 version (with the 32/96 split).

The only reason we made this a parameter is because of the AEAD construction where we use the zero block counter for creating the Poly1305 key, and encryption starts at block counter = 1.

In retrospect we could have made the API simpler by eliminating this parameter and always starting with zero.  Generating the Poly1305 key only requires a unique value for block counter, not any specific one.  We could have,  perhaps should have gone with 0xffffffff.

Unfortunately, by now it’s too late to make this change, as this algorithm is implemented in many libraries. That said, the only thing that is seeing a lot of usage is the AEAD, and for the AEAD the initial block counter is set at 1.

Yoav

> On 26 Jan 2019, at 5:20, Jeffrey Walton <noloader@gmail.com> wrote:
> 
> Hi Everyone,
> 
> This question is moved from another list to CFRG. It was suggested
> CFRG is a better forum for the question.
> 
> I'm working on test vectors for an implementation of the IETF's
> version of ChaCha from RFC 8439. According to Section 2.4, page 9
> (https://tools.ietf.org/html/rfc8439#section-2.4):
> 
>   The inputs to ChaCha20 are:
>      o  A 256-bit key
>      o  A 32-bit initial counter.  This can be set to any number, but will
>         usually be zero or one...
>      o  A 96-bit nonce.  In some protocols, this is known as the
>         Initialization Vector.
>      o  An arbitrary-length plaintext
> 
> Now a test vector. We set:
> 
>    Key - All 0's
>    IV - All 0's
>    Initial Counter Block - 0xfffffffe
>    Plaintext -  256 bytes of all 0's
> 
> After the first two 64-bit blocks the counter will wrap around to 0.
> This is where the problem arises.
> 
> One implementation I am aware wraps the block counter. It produces a keystream:
> 
> 032CC123482C31711F94C941AF5AB1F4155784332ED5348FE79AEC5EAD4C06C3
> F13C280D8CC49925E4A6A5922EC80E13A4CDFA840C70A1427A3CB699166991A5
> ACE4CD09E294D1912D4AD205D06F95D9C2F2BFCF453E8753F128765B62215F4D
> 92C74F2F626C6A640C0B1284D839EC81F1696281DAFC3E684593937023B58B1D
> 76B8E0ADA0F13D90405D6AE55386BD28BDD219B8A08DED1AA836EFCC8B770DC7
> DA41597C5157488D7724E03FB8D84A376A43B8F41518A11CC387B669B2EE6586
> 9F07E7BE5551387A98BA977C732D080DCB0F29A048E3656912C6533E32EE7AED
> 29B721769CE64E43D57133B074D839D531ED1F28510AFB45ACE10A1F4B794D6F
> 
> Another implementation I am aware wraps the block counter, but it also
> increments the high word of the nonce, similar to the way original
> ChaCha used a 64-bit block counter. It produces a keystream:
> 
> 032CC123482C31711F94C941AF5AB1F4155784332ED5348FE79AEC5EAD4C06C3
> F13C280D8CC49925E4A6A5922EC80E13A4CDFA840C70A1427A3CB699166991A5
> ACE4CD09E294D1912D4AD205D06F95D9C2F2BFCF453E8753F128765B62215F4D
> 92C74F2F626C6A640C0B1284D839EC81F1696281DAFC3E684593937023B58B1D
> 3DB41D3AA0D329285DE6F225E6E24BD59C9A17006943D5C9B680E3873BDC683A
> 5819469899989690C281CD17C96159AF0682B5B903468A61F50228CF09622B5A
> 46F0F6EFEE15C8F1B198CB49D92B990867905159440CC723916DC00128269810
> 39CE1766AA2542B05DB3BD809AB142489D5DBFE1273E7399637B4B3213768AAA
> 
> I don't believe the issue arises in Bernsein's version of ChaCha
> because the block counter is 64-bits and always starts at 0. Bernstein
> does not allow arbitrary values for the initial block counter. The
> constraint is unstated in Bernstein's paper on ChaCha, but it is
> obvious when examining his reference implementation (from chacha-ref.c
> version 20080118):
> 
>    void ECRYPT_ivsetup(ECRYPT_ctx *x,const u8 *iv)
>    {
>        x->input[12] = 0;
>        x->input[13] = 0;
>        x->input[14] = U8TO32_LITTLE(iv + 0);
>        x->input[15] = U8TO32_LITTLE(iv + 4);
>    }
> 
> My question is, what should happen when the block counter wraps?
> 
> Thanks in advance.
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg