On Tue, Feb 9, 2021 at 3:07 PM Niels Möller <[email protected]> wrote: > > [email protected] (Niels Möller) writes: > > > I would guess that means that we got 209 bytes, including the 16-byte > > poly1305 authentication tag. Message size is then 209 - 16 = 193 bytes. > > If the first byte is a TLS packet type, the "length: 192" in the next to > > last line makes sense if the packet type byte is excluded. Right? > > I've found one problem, although I don't see that it would cause > precisely the reported problem. It would result in incorrect > encrypt/decrypt of the data immediately after a call to chacha_crypt or > chacha_crypt32 with 129 <= (length % 256) <= 192. In code used only on > ppc64 with the new altivec chacha code enabled. > > Tentative patch below, but I need to extend the tests to get proper test > coverage of this case.
If needed, you can find Bernstein's reference implementation at https://cr.yp.to/chacha.html. Modify it for IETF's ChaCha and use it to generate test vectors. A set of 12x blocks would probably be a good choice. Or you can use the test vectors from Wei Dai's Crypto++. The project already generated test vectors for 1x, 4x and 12x blocks. The test vectors include Bernstein's ChaCha and the IETF version. Also see https://github.com/weidai11/cryptopp/blob/master/TestVectors/chacha.txt . You might also consider changing the project's governance to require a complete set of test vectors for each algorithm. If you are doing 4x blocks, then you need test vectors covering them. You should also use an independent program to generate them, like Bernstein's reference implementation. (I don't believe the IETF provides a reference implementation). Jeff _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
