Can we encrypt part of the XChaCha/XSalsa nonce?

Question

The xChaCha cipher detailed here extends the nonce 192bits and works as follows (from the link):

1. Pass the key and the first 16 bytes of the 24-byte nonce to HChaCha20 to obtain the subkey.
2. Use the subkey and remaining 8 byte nonce with ChaCha20 as normal (prefixed by 4 NUL bytes, since [RFC8439] specifies a 12-byte nonce).

My question is could we encrypt the 2nd part of the nonce by running an additional initial round (HChaCha20) with the 16 bytes of the nonce and the key?

We could use one of the two parts of the nonce as a counter by incrementing them, given they occupy the usual counter slots. I suppose the same question applies to XSalsa20.

I presume this would compromise something somewhere. It seems like a very simple and cheap way to make a brute force more difficult. The additional round(s) would take about 10ms.

EDIT - hopefully the below makes the idea (somewhat) clearer. My impoverished code is in javascript.

Note: HChaCha20 is initialized the same way as the ChaCha cipher, except that HChaCha20 uses a 128-bit nonce and has no counter. Instead, the block counter is replaced by the first 32 bits of the nonce.

//Encrypt
 subkey = hchacha20(key, nonce[0:15]);
 nonce[0]+=1; //or any part which occupies the usual counter block, nonce[0-4]?
 subkey2 = hchacha20(key, nonce[0:15]);
 nonce[0]-=1; //or..etc  
 subnonce = subkey2 ^ nonce[16:23]; 
 chacha20_nonce = "\x00\x00\x00\x00" + nonce[16:23];
 //Run ChaCha20 
 output = ciphertext + nonce[0:15] + subnonce);
 


//Decrypt    
 subkey = hchacha20(key, nonce[0:15]);
  nonce[0]+=1; //or any part which occupies the usual counter block, nonce[0-4]?
 subkey2 = hchacha20(key, nonce[0:15]); 
 subnonce = subkey2 ^ nonce[16:23]; 
 chacha20_nonce = "\x00\x00\x00\x00" + subnonce;
 //Run ChaCha20 
 output = plaintext;

Answer 1

First the XChaCha20-Poly1305 basics

• Why one may need XChaCha20

  ChaCha20 is 20 round from the ChaCha family. The Bernstein version of ChaChax has a 64-bit nonce and 64 bit counter. Bernstein argued that this should be enough in the XSalsa paper

  There is a standard argument that a 64-bit nonce is long enough. Nonce security does not mean unpredictability; it means uniqueness. Applications can generate a nonce as a monotonic timestamp or simply a counter 1,2,3,...

  For long-lived keys, the 64-bit nonce of ChaCa20 is too short to use securely since with the birthday attack around the 2^32 messages one will have 50% of hitting the same random nonce that will at least result in the loss of the confidentiality.

  XChaCha20 is based on the IETF version that uses 96-bit nonces.

• The security of ChaCha20-Poly1305 with random nonces

  The ietf' docs say that after around $2^{96}$ messages one should expect a collision with the birthday attack. 50% is very advantageous for the attacker and a more conservative one is generating at most $2^{80}$ nonce so that the collision probability is $\frac{1}{2^{32}}$. And, still, this $2^{80}$ message under one key should be enough for all. Therefore, the XChaCha20 is safe to use with random nonces. The security reduced to the security of the ChaCha20-Poly1305

• How the ChaCha20-Poly1305 works

  • The 128-bit key and the first 128-bit (16-byte) of the uniform random nonce is processed with the HChaCha20
  • The HChaCha20 returns two 128 bits.
  • The remaining 64-bit ( 8-byte) of the nonce is appended with 4 null bytes.

    xchacha20_encrypt(key, nonce, plaintext, blk_ctr = 0):
         subkey = hchacha20(key, nonce[0:15])
         chacha20_nonce = "\x00\x00\x00\x00" + nonce[16:23]
    
         return chacha20_encrypt(subkey, chacha20_nonce, plaintext, blk_ctr)
    

Back to Questions

My question is could we encrypt the 2nd part of the nonce by running an additional initial round (HChaCha20) with the 16 bytes of the nonce and the key?

I'm reading this like this

```
xchacha20_encrypt(key, nonce, plaintext, blk_ctr = 0):
     subkey = hchacha20(key, nonce[0:15])
     subNonce = hchacha20(key + nonce[0:15], nonce[16:23])
     chacha20_nonce = "\x00\x00\x00\x00" + subNonce
     return chacha20_encrypt(subkey, chacha20_nonce, plaintext, blk_ctr)
```

To decrypt the other side must follow the same steps since they are not reversible! Therefore you need to send the nonce[16:23] as it is.

Therefore is no need for this since we expect that the nonce is generated uniform randomly. If you want to really do it, you can, you will get no advantage on the brute-force side. The attacker will still need to search over 128-bit. As a result, this adds nothing at all to the security.

I presume this would compromise something somewhere. It seems like a very simple and cheap way to make a brute force more difficult. The additional round(s) would take about 10ms.

It doesn't compromise anything at all but also doesn't provide any at all in the security of the XChaCha20-Poly1305. The brute-force attack, as mentioned above, will still need for a 128-bit key search.