diff options
author | tb <> | 2020-12-15 16:04:49 +0000 |
---|---|---|
committer | tb <> | 2020-12-15 16:04:49 +0000 |
commit | 504bf1627e800924a2e652013e03bb332dbcb7e3 (patch) | |
tree | 846602078876e31b51a7a0cbda8fb147198266a3 /src/lib/libcrypto | |
parent | 49f8c65dfe3b1b8b8e597c81e67ab5078e7372a1 (diff) | |
download | openbsd-504bf1627e800924a2e652013e03bb332dbcb7e3.tar.gz openbsd-504bf1627e800924a2e652013e03bb332dbcb7e3.tar.bz2 openbsd-504bf1627e800924a2e652013e03bb332dbcb7e3.zip |
Use natural sizes for S3I(s)->tmp's *_md arrays
It is a historical artifact that cert_verify_md[], finish_md[] and
peer_finish_md[] are twice as large as they need to be. This is
confusing, especially for finish_md[] and peer_finish_md[] which are
copied to to previous_client_finished[] and previous_server_finished[]
which are only half as large. It is easy to check that they will never
get more than EVP_MAX_MD_SIZE data written to them.
In 1998, EVP_MAX_MD_SIZE was 20 bytes long (for SHA-1). This got bumped to
16+20 for the SSLv3-specific md5+sha1. Apparently under the impression
that EVP_MAX_MD_SIZE was still 20 bytes, someone else doubled finish_md[]'s
size to EVP_MAX_MD_SIZE*2 and added /* actually only needs to be 16+20 */.
A bit later finish_md[] was split up, and still a bit later the comment was
amended for TLSv1. Shortly thereafter SHA-512 required a bump of
EVP_MAX_MD_SIZE to 64 by a third person and we have been carrying 192 bytes
of untouched memory in each of our SSLs ever since.
ok inoguchi jsing (jsing had the same diff)
Diffstat (limited to 'src/lib/libcrypto')
0 files changed, 0 insertions, 0 deletions