I'm unclear on what EVP_CIPHER's interface guarantees are, but our EVP_AEAD
APIs are documented to allow in/out buffers to alias as long as out is <=
in. This matches what callers might expect from a naive implementation.
Our AES-GCM EVP_AEADs, which share code with OpenSSL, have tended to match
this pattern too. For ChaCha, of chacha-{x86,x86_64,armv4,armv8}.pl and the
C implementation, all seem satisfy this (though it's possible I don't have
complete coverage) except for chacha-x86.pl. That one works if in == out,
but not if out is slightly behind.
We were able to reproduce problems when in = out + 1. The SSE3 code
triggers if the input is at least 256 bytes and the non-SSE3 code if the
input is at least 64 bytes. The non-SSE3 code is because the words in a
block are processed in a slightly funny order (0, 4, 8, 9, 12, 14, 1, 2, 3,
5, 6, 7, 10, 11, 13, 15). I haven't looked at the SSE3 case carefully, but
I expect it's something similar.
Could the blocks perhaps be processed in a more straight-forward ordering,
so that chacha-x86.pl behaves like the other implementations? (It's nice to
avoid bugs that only trigger in one implementation.) Or is this order
necessary for something?
David
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
