summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto
diff options
context:
space:
mode:
authortb <>2020-12-15 16:04:49 +0000
committertb <>2020-12-15 16:04:49 +0000
commit504bf1627e800924a2e652013e03bb332dbcb7e3 (patch)
tree846602078876e31b51a7a0cbda8fb147198266a3 /src/lib/libcrypto
parent49f8c65dfe3b1b8b8e597c81e67ab5078e7372a1 (diff)
downloadopenbsd-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