Chiebot-Mirror/boringssl - boringssl - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
David Benjamin	ce65c1daf8	Add DSA_bits and DH_bits. More OpenSSL compatibility functions. Change-Id: I8e9429fcbc3e285f4c4ad9bdf4c1d9d3c73c3064 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53925 Commit-Queue: David Benjamin <davidben@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>	3 years ago
David Benjamin	16a94930ac	Add various OpenSSL compatibility functions. The non-_ex EVP_CIPHER_CTX Final functions are a bit interesting. Unlike EVP_DigestFinal(_ex), where the non-_ex version calls EVP_MD_CTX_cleanup for you, the EVP_CIPHER_CTX ones do not automatically cleanup. EVP_CipherFinal and EVP_CipherFinal_ex are identical in all releases where they exist. This appears to date to OpenSSL 0.9.7: Prior to OpenSSL 0.9.7, EVP_MD_CTX and EVP_CIPHER_CTX did not use void* data fields. Instead, they just had a union of context structures for every algorithm OpenSSL implemented. EVP_MD_CTX was truly cleanup-less. There were no EVP_MD_CTX_init or EVP_MD_CTX_cleanup functions at all. EVP_DigestInit filled things in without reference to the previous state. EVP_DigestFinal didn't cleanup because there was nothing to cleanup. EVP_CIPHER_CTX was also a union, but for some reason did include EVP_CIPHER_CTX_init and EVP_CIPHER_CTX_cleanup. EVP_CIPHER_CTX_init seemed to be optional: EVP_CipherInit with non-NULL EVP_CIPHER similarly didn't reference the previous state. EVP_CipherFinal did not call EVP_CIPHER_CTX_cleanup, but EVP_CIPHER_CTX_cleanup didn't do anything. It called an optional cleanup hook on the EVP_CIPHER, but as far as I can tell, no EVP_CIPHER implemented it. Then OpenSSL 0.9.7 introduced ENGINE. The union didn't work anymore, so EVP_MD_CTX and EVP_CIPHER_CTX contained void* with allocated type-specific data. The introduced EVP_MD_CTX_init and EVP_MD_CTX_cleanup. For (imperfect!) backwards compatibility, EVP_DigestInit and EVP_DigestFinal transparently called init/cleanup for you. EVP_DigestInit_ex and EVP_DigestFinal_ex became the more flexible versions that left init/cleanup to the caller. EVP_CIPHER_CTX got the same treatment with EVP_CipherInit/EVP_CipherInit_ex, but not EVP_CipherFinal/EVP_CipherFinal_ex. The latter did the same thing. The history seems to be that 581f1c84940d77451c2592e9fa470893f6c3c3eb introduced the Final/Final_ex split, with the former doing an auto-cleanup, then 544a2aea4ba1fad76f0802fb70d92a5a8e6ad85a undid it. Looks like the motivation is that EVP_CIPHER_CTX objects are often reused to do multiple operations with a single key. But they missed that the split functions are now unnecessary. Amusingly, OpenSSL's documentation incorrectly said that EVP_CipherFinal cleaned up after the call until it was fixed in 538860a3ce0b9fd142a7f1a62e597cccb74475d3. The fix says that some releases cleaned up, but there were, as far as I can tell, no actual releases with that behavior. I've put the new Final functions in the deprecated section, purely because there is no sense in recommending two different versions of the same function to users, and Final_ex seems to be more popular. But there isn't actually anything wrong with plain Final. Change-Id: Ic2bfda48fdcf30f292141add8c5f745348036852 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50485 Reviewed-by: Adam Langley <agl@google.com>	3 years ago
David Benjamin	cfafcd454f	Deduplicate d2i and i2d documentation. There are a lot of d2i and i2d functions, and there will be even more once asn1.h and x509.h are properly documented. We currently replicate the text in each, but as a result a miss a few points: - The i2d outp != NULL, outp == NULL case isn't documented at all. - We should call out what to do with inp after d2i. - Unlike our rewritten functions, object reuse is still quite rampant with the asn1.h functions. I hope we can get rid of that but, until we can, it would be nice to describe it in one place. While I'm here, update a few references to the latest PKCS#1 RFC, and try to align how we reference ASN.1 structures a bit. The d2i/i2d functions say "ASN.1, DER-encoded RSA private key" while the CBS/CBB functions say "DER-encoded RSAPrivateKey structure". Bug: 426 Change-Id: I8d9a7b0aef3d6d9c8240136053c3b1704b09fd41 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49906 Reviewed-by: Adam Langley <agl@google.com>	3 years ago
Adam Langley	fb0c05cac2	acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>	5 years ago