See also 8129ac6ac4c0ca3a488c225cde580ede7dabe874 and
81198bf323ea9deda907714170d329ca7d2ff01f from upstream.
In trying to figure out why ASan (which normally catches overlapping
memcpys) didn't flag this, I noticed that we actually don't have tests
for empty inputs. I've added them to cipher_tests.txt where missing and
fixed a bad assert in ofb.c.
ASan still doesn't flag this because LLVM even requires memcpy handle
dst == src. Still, fixing it is less effort than getting a clear answer
from GCC and MSVC. Though this puts us in the frustrating position of
trying to follow a C rule that our main toolchain and sanitizer disavow.
https://bugs.llvm.org/show_bug.cgi?id=11763https://reviews.llvm.org/D86993
Change-Id: I53c64a84834ddf5cddca0b3d53a29998f666ea2f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46285
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
All our EVP_CIPHERs are deterministic, so there's usually no point in
testing only one direction. Some of the ECB tests were missing free
decryption tests. CTR is the same in both directions, but we ought to
test the API agrees. OFB vectors are doubled up, so we can merge them
together. Plus there are typos in the OFB-AES192.Decrypt tests, also
present upstream, so we weren't actually testing everything we should.
(I haven't removed the direction-specific logic altogether since the
tests imported from nist_cavp rely on it. Though there may be something
to be said for running them both ways since they don't actually double
them up...)
Change-Id: I36a77d342afa436e89ad244a87567e1a4c6ee9dc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46284
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
David Benjamin
Adam Langley