[9front] chacha(2): mention problems that can arise with the chacha algorithm

[9front] chacha(2): mention problems that can arise with the chacha algorithm

[kemal]

[-- Attachment #1: Type: text/plain, Size: 363 bytes --]

hello,

while developing a small program for fun that uses chacha,
i realised there were some important information missing
in the chacha(2) manpage.

i have added sections to the manpage that mentions
the IETF chacha's block counter overflow problem, and
a nonce reuse risk.

please tell me if i made a grammar or a technical mistake
somewhere.

(diff attached)

[-- Attachment #2: diff --]
[-- Type: application/octet-stream, Size: 1275 bytes --]

diff -r d588a54f841a sys/man/2/chacha
--- a/sys/man/2/chacha	Mon May 17 13:46:44 2021 -0700
+++ b/sys/man/2/chacha	Tue May 18 00:41:08 2021 +0300
@@ -130,6 +130,28 @@
 that is included in the
 .I tag
 calculation, but not encrypted.
+.SH BUGS
+.PP
+Originally Chacha had a nonce size of 64 bits. IETF decided to bump the nonce size to 96 bits.
+This decision had a cost, the block counter is now 32 bits so the bigger nonce fits in the key stream.
+So encrypting data bigger than 256 GB with a same key and nonce will cause problems, as the counter will overflow.
+This will cause undefined behaviour.
+If this can cause a problem to you, generate a 64 bit (8 byte) nonce instead and while calling
+.I setupChachastate
+pass 8 to the argument
+.IR ivlen .
+.PP
+If a key is going to be used more than once, generating random nonces is risky.
+As the nonce is short, nonce reuse might happen, which will cause us to use a key stream twice.
+In these cases it is recommended to use XChacha by generating nonces 
+.B XChachaIVlen
+big, and passing
+.B XChachaIVlen
+to the
+.I ivlen
+argument while calling
+.IR setupChachastate .
+Another solution is to increment the nonce instead of generating a new one while using a key again.
 .SH SOURCE
 .B /sys/src/libsec
 .SH SEE ALSO