0

Setting all 48 ChaCha state bytes (key, nonce, initial counter) from one result of strong hash function like sha3-384 or blake2b - correct usage? or bad practice?

PS: using original chacha20 (8bytes nonce/8bytes counter) for encrypting one long file or one-way tcp stream, not multiple small files/messages.

Yuri Myakotin
  • 1
  • 2
  • Welcome to Cryptography.SE? What is the aim here? are you afraid of the 96 bit nonce and 32-bit counter? Why don't use ChaCha20 with the bundled authentication; Poly1305? Yes, xChaCha20-Poly1305 rfc-draft extends the nonce to 192 bits – kelalaka Sep 16 '23 at 08:57
  • As i said, aim = encrypting one-way tcp stream (two way stream uses 2 totally different keys/nonces for Alice->Bob and Bob->Alice), or just a very long file. Original 64bit counter means i can send terabytes of data without changing key/nonce. And btw, blake3 keyed-mac even faster than Poly1305, especially with avx2/avx512 cpu instructions. – Yuri Myakotin Sep 16 '23 at 09:28
  • 1
    @YuriMyakotin It's best to chunk the data, so you'd typically increment the nonce for each 16 KiB chunk of plaintext, for example. Then each stream uses a different key. You don't need a 64-bit counter. Look at the STREAM and CHAIN constructions as well as libsodium's secretstream. – samuel-lucas6 Sep 16 '23 at 09:35
  • chunking - yes, but is there any security reason for zeroing counter each next chunk instead of continuing, if counter is 64 (or even 128, entire "counter and nonce" part ) bit? – Yuri Myakotin Sep 16 '23 at 10:24
  • @YuriMyakotin The internal counter is for the block, not chunks. ChaCha20 operates on 64 byte (512-bit) blocks, so your message is processed one block at a time internally. Most APIs don't even expose the internal counter. If you change the nonce, there's no need to keep the counter going. The counter is just there so that the output is different for each block when the same key and nonce are used. There's no security benefit to modifying the counter as well as the nonce. In fact, you're more likely to make a mistake/cause a vulnerability interacting with the counter. – samuel-lucas6 Sep 16 '23 at 11:32
  • @YuriMyakotin Zeroing counter is more common. It makes it more transparent and harder to make mistakes. You can also detect counter overflow. See here about different posibilities: https://crypto.stackexchange.com/questions/17699/strategy-for-random-ctr-initial-counter-values – LightBit Sep 16 '23 at 11:39
  • @samuel-lucas6 i known how to stream cipher works :) just asking about security reasons for separating counter/nonce in chacha instead of using 64 or even entire 128-bits as big counter. As i understand, chacha20 is secure if at least one byte in entire 48-bytes state (key-counter-nonce) not same for each block and these 48-bytes never repeating? And no real difference what bytes you changing? – Yuri Myakotin Sep 16 '23 at 12:10
  • @YuriMyakotin Yes, either the nonce or counter must not repeat with the same key, and the key should be uniformly random. Theoretically, you can use the nonce and counter part of the state as a key. However, it's not interoperable with the RFC and thus existing implementations. It also provides no practical security benefit. So, is it 'correct usage'? No. Is it 'bad practice'? Most people would probably say yes because you're deviating from the standard. – samuel-lucas6 Sep 16 '23 at 13:01
  • @samuel-lucas6 thanks! – Yuri Myakotin Sep 16 '23 at 15:07

1 Answers1

1

I assume input to a hash function would be key and nonce.

I think it is ok to hash key and nonce, if you want to use bigger nonce as XChaCha does something similar to extend nonce, but I would keep counter on zero as does XChaCha.

Recommended usage would be to use XChaCha.

LightBit
  • 1,649
  • 13
  • 27
  • I would also recommend just using XChaCha20. That's more efficient than using a hash function for key derivation/nonce extension, and there's no need to modify the internal counter. – samuel-lucas6 Sep 16 '23 at 09:31