tree 4aa52a455d356139ee9963dc2d25c0084ef19cf8
parent 56d3ad9d23bc130aa9404bfdd1957fe81b3ba498
author David Benjamin <davidben@google.com> 1705770616 -0500
committer Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> 1706742580 +0000

Fix strict aliasing issues with DES_cblock

After all, we have to keep this robust, modern cipher conforming to C
well-definedness expectations!

These functions should have simply taken uint8_t* pointers. Make
internal _ex variants that fix this. I've not bothered updating the
public APIs because it will cause a ton of downstream churn and make
those APIs even more OpenSSL-incompatible.  (OpenSSL's APIs take a
const-incorrect uint8_t (*in)[8]. Both our struct and their pointers
expect callers to call with &foo.) This does not seem worth the trouble.

Also since the underlying functions now access as uint8_t*, I suspect
this broadly fixes strict aliasing issues with callers that cast from a
byte array. (Though perhaps in->bytes should be (const uint8_t*)in?)

Ideally c2l and l2c would be replaced with CRYPTO_load_u32_le and
CRYPTO_store_u32_le. (It's a little rude for a header to squat those
names, especially when those name often vary in endianness.) I did that
in a couple places where we'd otherwise increment a pointer declared
with the funny array parameter syntax.  Otherwise I left it alone for
now.

Fixed: 683
Change-Id: I7b0d8b2a16697095ebf42a71482c4ba805a193e4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65690
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>