Using shortened key for Chacha20

Question

As I understand it, the chacha20 algorithm is designed for use with 256-bit keys, but is it possible to use shorter keys than this without compromising the security? Say if i use a 192-bit key and set the final 2x32-bit bit words in the matrix as public constants can i expect 192-bit security?

Answer 1

Surely. The constant words - i.e. words 0-3 are magic numbers that correspond to the byte string expand 32-byte k. You can change 32 to 16 and repeat the 128-bit key twice, although nobody gave formal definition for 24, which means there can be interoperability problems.

Answer 2

Since self-answers are encouraged, I have recently found a document by Bernstein that confirms its safe to zero pad shorter keys to larger sizes for salsa20 (since chacha is a natural upgrade to salsa with better diffusion then its safe to assume its safe for chacha as well): https://cr.yp.to/snuffle/keysizes.pdf

Although its important to note that in that example he specifically zero pads 80-bit keys to 128-bits to conform with eSTREAM requirements, and still encourages the use of 256-bit keys.

Answer 3

Jump to the bolded "OTOH" if you want my recommendation on how to use a 192 bit key.

Assuming that the underlying PRF is secure(not quite true under all scenarios depending on modifications, see asterisk)* and that: -You leave enough room for the counter for your use case(ie how many 512 bit blocks you need per message under a given key) -You leave enough room for the nonce so that each time you encrypt a message you always use a unique nonce(with sufficiently high probability over the entire lifetime of the key) given your nonce generation method -You have asymmetric constants that take up enough area in the state to prevent an attacker from exploiting symmetries in the underlying PRP

Then it might be possible that this variation on ChaCha/Salsa20 might be secure. Might be possible is the key word here. I'd prefer that you contact a cryptographer to analyze your particular variation to ensure that your modifications don't fuck anything up somehow.

At minimum, you do have the option of a state that looks like this:

• 24 byte key(ie the 192 bit key)
• 8 byte key field static padding(to fill in the space)
• 16 byte asymmetric constant*
• 16 byte space for nonce and counter value(because a single 512 output block is kinda limiting and you need nonces for security)

OTOH, there's an easy alternative if you need to shoehorn 192 bit keys into the 256 key size of ChaCha/Salsa20:

1. Take a secure hash(ie for convenience and sharing the same general security pedigree, use one of the Blake hashes). Use it to instantiate HKDF.
2. Shove your 192 bit key into the HKDF-Extract** and get the IKM(should be at least 192 bits or larger).
3. Use HKDF-Expand to turn the IKM into a 256 bit key.
4. Use your newly expanded 256 bit key as input into ChaCha/Salsa20.

We don't need to worry about any special interactions with the stream cipher now. Of course, this scheme only retains the 2^192 security since the set of possible keys is at most 2^192 and not 2^256. Everything else though will remain the same so you can treat this similarly to normal ChaCha/Salsa20 in terms of nonce generation and maximal block output allowed(and therefore ciphertext).

PS: Can I also advise you use XChaCha20+Poly-1305? Ideally use a library like monocypher for this. It's a AEAD*** that's fast and it handles random nonces extremely well. No need to worry about keeping state or counters. Ideally you make a call to a CSPRNG but if your PRNG is sufficiently well seeded and unique, you could probably just use that if all else fails. Or you could fall back to using a unique sequence like counters/lfsrs if that's practical. It also provides integrity protection by rejecting forgeries or attempts in inject fake/malicious data to users/programs really fast thanks to Poly-1305. You can add metadata to said integrity protection(like packet header, file name, and more).****

* As it turns out, the underlying PRP that is formed by iterating the ChaCha/Salsa20 round function 20 times has symmetries that can be exploited by an attacker who can control a large portion of the state. In the stream ciphers, cryptographers counter this potential weakness by forcing 16 bytes of the state to be an asymmetric constant(namely "expand 32-byte k" encoded as ascii/utf-8). If you try to repurpose the design for anything else, you need to be careful to take into account this issue. And ideally ask a cryptographer to review the design carefully before using it. This sort of thing can be easy to accidentally fuck up.

** Technically speaking since we assume the 192 bit key is uniformly random and secret already we can skip the HKDF extract step(which is geared towards entropy extraction of the key material into a uniformly random secret IKM among other things) and jump to HKDF expand by treating the 192 bit key as the IKM itself.

*** This AEAD scheme allows invisible salamanders which means an attacker who can provide/manipulate in use keys can attempt to make the same ciphertext decrypt to two different valid plaintexts, to unknown consequences. Carefully review your design if you have more than 1 user interacting with a given ciphertext or a scenario where an attacker can control/manipulate encryption keys. Key commitment by for example taking an appropriately domain separated hash of the key and then appending it to the ciphertext to verify that you are using the right key can work.

**** Keep in mind secure and strict canonicalization of the metadata that's fed into the "Additional Data" part of AEAD. Failure to properly canonicalize the data can lead to all sorts of fun attacks. Also make sure that the same canonicalized view that's used for the MAC is also used for whatever you actually use the metadata for. Parser differentials are fun in a potentially security breaking way.