4 ms·
The 128-bit counter would work, and would remove the 32 bytes of overhead. The speed difference however is fairly negligible, and you would lose forward secrec
by loup-vaillant 7y ago
The 128-bit counter would work, and would remove the 32 bytes of overhead. The speed difference however is fairly negligible, and you would lose forward secrecy in the process (if your unrotated seed gets stolen, all past random numbers are revealed).
Now I wonder where this 768 bytes could possibly come from. It's only a multiple of 256, which can only take advantage of 128-bit vectors (4 blocks at a time). Ideally you want an 8 way parallelism (AVX2) or even 16 way parallelism (AVX-512). That is, either 512 byte blocks, or 1024 byte blocks.
- loeg 7y ago128-bit counter and key rotation are not mutually exclusive. I believe the 768 byte figure comes from DJB's blog on fast key erasure[1]. Why he picked 768, I do not know. [1]: https://blog.cr.yp.to/20170723-random.html https://blog.cr.yp.to/20170723-random.html
- loup-vaillant 7y agoOh, I see. Then people blindly copied it, without taking into account that Chacha20 has bigger blocks than AES, and could benefit from vector implementations (while AES has bit slicing or AES-NI).
- bscphil 7y ago> Now I wonder where this 768 bytes could possibly come from. This is totally implementation defined, it's not required by the spec. As loeg says (below) I was looking at a reference implementation by djb. I did a quick skim of OpenBSD's arc4random (which also uses ChaCha20) and if I'm reading it correctly, it rekeys every 1024 bytes. > Ideally you want an 8 way parallelism (AVX2) or even 16 way parallelism (AVX-512) My guess is that 768 was thought to be a decent enough trade-off between maximum and average latency for calls to the CSPRNG. I wouldn't be surprised to see that most implementations that are optimized for specific CPU architectures use different values.