# How to find out the block size of Xchacha20 in Libsodium?

I heard that Xchacha20 works like a block cipher so that even if it wants to encrypt one byte, it will do the work of at least one block. So technically it works similar to a block cipher in counter mode.

I want to find out the size of this block, which represents the minimum work that Xchacha20 can do.

How to find out? Specifically in Libsodium. I want to see it (not just believe it blindly). Any idea where to look?

TL;DR; ChaCha's block size is 64-byte i.e. 512-bit.

Xchacha20 extends the nonce of ChaCha20 without changing the function of ChaCha20. The aim of Xchacha20 is to extend the 128-bit nonce size of ChaCha20 to 192-bit in order to generate random nonces to use safely in the long-lived keys without the fear of the nonce-collision.

The RFC 7539 in Section 2.3 mentions clearly.

2.3. The ChaCha20 Block Function

The ChaCha block function transforms a ChaCha state by running multiple quarter rounds.

The inputs to ChaCha20 are:

• A 256-bit key, treated as a concatenation of eight 32-bit little-endian integers.

• A 96-bit nonce, treated as a concatenation of three 32-bit little- endian integers.

• A 32-bit block count parameter, treated as a 32-bit little-endian integer.

The output is 64 random-looking bytes.

The ChaCha, a variant of Salsa20 paper;

This paper assumes that the reader is familiar with Salsa20, and focuses on the changes from Salsa20 to ChaCha

on the intro

The Salsa20/20 stream cipher expands a 256-bit key into $$2^{64}$$ randomly accessible streams, each containing $$2^{64}$$ randomly accessible $$64$$-byte blocks.

And the The Salsa20 family of stream ciphers paper wrote it more clearly;

Salsa20 generates the stream in 64-byte (512-bit) blocks

Some words on this

I heard that Xchacha20 works like a block cipher

Salsa and ChaCha are stream ciphers both build on Pseudo-Random Function (PRF).

A PRF defined over $$(K,X,Y)$$: $$F: K \times X \mapsto Y$$ such that exists efficient algorithm to evaluate $$F(k,x)$$

They use CTR mode to turn a PRF into a stream cipher. CTR mode is designed for PRF by Whitfield Diffie and Martin Hellman in 1979;

In contrast, a block cipher is a family of permutations and is expected to be a Pseudo-Random Permutation (PRP). A PRP defined over $$(K,X)$$: $$E: K \times X \mapsto X$$ such that:

1. There exists efficient algorithm to evaluate $$E(k,x)$$
2. The function $$E( k, \cdot )$$ is one-to-one ( and therefore permutation)
3. There exists efficient inversion algorithm $$D(k,x)$$

Note that a PRP is also PRF.

The CTR mode doesn't require the inverse of the function and therefore enables more range of functions to use. If we fix the output space into the same space for PRF's then there are $$2^{n^{2^n}}$$ PRFs and $$2^n!$$ PRPs from $$n$$-bit input space to $$n$$-bit output space.

If you need to use a PRP in the CTR mode then you need to be careful on the PRF-PRF switching lemma. , Bellare et. al, 97 provide the security bounds.

In contrast to conventional stream cipher that output bits per clock, Salsa and ChaCha both produce long outputs per encryption by design and are still stream ciphers.