[openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

[David Benjamin via RT]

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