This may as well be computed from block_size. This reduces the
per-EVP_CIPHER_CTX memory usage slightly.
Update-Note: It doesn't look like anyone is reading into this field. If
they are, we can ideally fix it, or revert this if absolutely necessary.
Change-Id: Ieef9177bed1671efca23d4f94d3d528f82568fc6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45884
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CVE-2021-23840
(Imported from upstream's 6a51b9e1d0cf0bf8515f7201b68fb0a3482b3dc1.)
This differs slightly from upstream's version:
- EVP_R_OUTPUT_WOULD_OVERFLOW didn't seem necessary when ERR_R_OVERFLOW
already exists. (Also since we use CIPHER_R_*, it wouldn't have helped
with compatibility anyway. Though there's probably something to be
said for us folding CIPHER_R_* back into EVP_R_*.)
- For simplicity, just check in_len + bl at the top, rather than trying
to predict the exact number of bytes written.
Update-Note: Passing extremely large input lengths into EVP_CipherUpdate
will now fail. Use EVP_AEAD instead, which is size_t-based and has more
explicit output bounds.
Change-Id: I31835c89dcdecb6b112828f57deb798dc7187db5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45685
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Change-Id: I814f55742910c519e9b64aca1b15a4d754adc541
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44944
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
David Benjamin
Adam Langley
Adam Langley