Hello,
nisse@lysator.liu.se (Niels Möller) writes:
nisse@lysator.liu.se (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?
That's exactly the case (under TLS 1.3). As the protocol uses separate keys for handshake and application traffic (and the error happens in sending application data and no post-handshake messages are exchanged), I guess you can also assume that the same data (all bytes are 0x2) with different lengths is fed into chacha_crypt* in the failing test case (mini-record-2).
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.
Thank you so much! The patch fixes the issue (tested on gcc cfarm).
In the gdb trace, I see nettle_chacha_poly1305_encrypt() is called with the following length pattern: 128, 63, 128, 64, 192, 1, 192, 2. I can try to create a test case if necessary.
Also: thank you Andreas for looking into it.
Regards,