summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/evp/e_chacha20poly1305.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* If EVP_CIPHER_CTX_ctrl(3) is called on EVP_chacha20_poly1305(3)schwarze2024-12-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | with an unsupported control command, return -1 rather than 0 to the caller to indicate the error because in general, these control hooks ought to return -1 for unsupported control commands and 0 for other errors, for example other invalid arguments. Not a big deal because this change does not change when operations succeed or fail, and because callers are unlikely to pass unsupported control commands in the first place. The only functional change is that if a calling program inspects the ERR(3) stack after this failure, it will now find the correct error code rather than nothing. Even that wasn't a huge problem because for most EVP_CIPHER control failures, getting no reason for the error is the usual situation. Then again, giving the reason when easily possible may occasionally be useful. OpenSSL also returns -1 in this case, so it also helps compatibility a tiny bit. Found while auditing the return values of all the EVP_CIPHER control hooks in our tree. This was the only fishy one i found. OK tb@
* Fix in-place decryption for EVP_chacha20_poly1305()tb2024-05-221-3/+3
| | | | | | | | | | | | | Take the MAC before clobbering the input value on decryption. Fixes hangs during the QUIC handshake with HAProxy using TLS_CHACHA20_POLY1305_SHA256. Found, issue pinpointed, and initial fix tested by Lucas Gabriel Vuotto: Let me take this opportunity to thank the HAProxy team for going out of their way to keep supporting LibreSSL. It's much appreciated. See https://github.com/haproxy/haproxy/issues/2569 tweak/ok jsing
* Hide public symbols in evp.hbeck2024-04-091-1/+4
| | | | | | largely mechanically done by the guentherizer 9000 ok tb@
* Some Australians don't like voids eithertb2023-12-301-3/+3
|
* Fix a return value confusion in chacha20_poly1305_cipher()tb2023-12-151-2/+2
| | | | | | | | | On overlong input, chacha20_poly1305_cipher() would return 0, which in EVP_CipherUpdate() and EVP_CipherFinal() signals success with no data written since EVP_CIPH_FLAG_CUSTOM_CIPHER is set. In order to signal an error, we need to return -1. Obviously. ok jsing
* Fix EVP_CIPHER_CTX_iv_length()tb2023-09-281-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In today's episode of "curly nonsense from EVP land" we deal with a quite harmless oversight and a not too bad suboptimal fix, relatively speaking. At some point EVP_CIPHER_{CCM,GCM}_SET_IVLEN was added. It modified some object hanging off of EVP_CIPHER. However, EVP_CIPHER_CTX_iv_length() wasn't taught about this and kept returning the hardcoded default value on the EVP_CIPHER. Once it transpired that a doc fix isn't going to cut it, this was fixed. And of course it's easy to fix: you only have to dive through about three layers of EVP, test and set a flag and handle a control in a couple methods. The upstream fix was done poorly and we begrudgingly have to match the API: the caller is expected to pass a raw pointer next to a 0 length along with EVP_CIPHER_GET_IV_LENGTH and the control handler goes *(int *)ptr = length in full YOLO mode. That's never going to be an issue because of course the caller will always pass a properly aligned pointer backing a sufficient amount of memory. Yes, unlikely to be a real issue, but it could have been done with proper semantics and checks without complicating the code. But why do I even bother to complain? We're used to this. Of note here is that there was some pushback painting other corners of a bikeshed until the reviewer gave up with a resigned That kind of changes the semantics and is one extra complexity level, but [shrug] ok... Anyway, the reason this matters now after so many years is that rust-openssl has an assert, notably added in a +758 -84 commit with the awesome message "Docs" that gets triggered by recent tests added to py-cryptography. Thanks to Alex Gaynor for reporting this. Let me take the opportunity to point out that pyca contributed to improve rust-openssl, in particular its libressl support, quite a bit. That's much appreciated and very noticeable. Regress coverage to follow in subsequent commits. Based on OpenSSL PR #9499 and issue #8330. ok beck jsing PS: A few macros were kept internal for now to avoid impact on the release cycle that is about to finish. They will be exposed after release.
* Update references from RFC 7539 to RFC 8439tb2023-08-241-3/+3
| | | | | | | | RFC 7539 was superseded by RFC 8439, incorporating errata and making editorial improvements. Very little of substance changed, in particular section numbers remain the same. Prompted by a question from schwarze
* Unbreak the namespace build after a broken mk.conf and tool misfire hadbeck2023-07-071-4/+1
| | | | | | | | me aliasing symbols not in the headers I was procesing. This unbreaks the namespace build so it will pass again ok tb@
* Hide symbols in hkdf, evp, err, ecdsa, and ecbeck2023-07-071-1/+4
| | | | | | (part 2 of commit) ok jsing@
* Make the cleanup() method return an int againtb2023-03-011-2/+4
| | | | | | | | | This partially reverts jsing's OpenBSD commit b8185953, but without adding back the error check that potentialy results in dumb leaks. No cleanup() method in the wild returns anything but 1. Since that's the signature in the EVP_CIPHER_meth_* API, we have no choice... ok jsing
* Make internal header file names consistenttb2022-11-261-2/+2
| | | | | | | | | | | | | | | | Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names used for internal headers. Move all these headers we inherited from OpenSSL to *_local.h, reserving the name *_internal.h for our own code. Similarly, move dtls_locl.h and ssl_locl.h to dtls_local and ssl_local.h. constant_time_locl.h is moved to constant_time.h since it's special. Adjust all .c files in libcrypto, libssl and regress. The diff is mechanical with the exception of tls13_quic.c, where #include <ssl_locl.h> was fixed manually. discussed with jsing, no objection bcook
* Stop pretending that EVP_CIPHER cleanup can fail.jsing2022-09-131-4/+2
| | | | | | | Now that EVP_CIPHER is opaque, stop pretending that EVP_CIPHER cleanup can fail. ok tb@
* chacha20_poly1305_cleanup() should return 1tb2022-08-301-2/+2
| | | | | | Otherwise EVP_CIPHER_CTX_cleanup() leaks, as spotted by the ASAN CI. ok jsing
* fix indent and zap trailing whitespacetb2022-08-211-3/+3
|
* Provide EVP_chacha20_poly1305()jsing2022-08-201-5/+252
| | | | | | | | | | | EVP_chacha20_poly1305() is an EVP_CIPHER implementation of the ChaCha20-Poly1305 AEAD. This is potentially used to provide encryption for the QUIC transport layer. Where possible, this should be avoided in favour of the significantly saner EVP_AEAD interface. ok tb@
* Remove bogus length checks from EVP_aead_chacha20_poly1305()jsing2022-08-201-27/+1
| | | | | | | | | The length checks for EVP_aead_chacha20_poly1305() seal/open were incorrect and are no longer necessary (not to mention that the comment failed to match the code). Remove these since the underlying ChaCha implementation will now handle the same sized inputs at these functions can. Issue flagged by and ok tb@
* Cast nonce bytes to avoid undefined behaviour when left shifting.jsing2019-03-271-3/+3
| | | | | | Reported by oss-fuzz, really fixes issue #13805. ok beck@ tb@
* Cast nonce bytes to avoid undefined behaviour when left shifting.jsing2019-03-241-3/+3
| | | | | | Reported by oss-fuzz, fixes issue #13805. ok beck@ tb@
* add support for xchacha20 and xchacha20-poly1305dlg2019-01-221-1/+122
| | | | | | | xchacha is a chacha stream that allows for an extended nonce, which in turn makes it feasible to use random nonces. ok tb@
* Remove EVP_aead_chacha20_poly1305_old() now that the original/oldjsing2017-08-281-80/+27
| | | | chacha20-poly1305 cipher suites have been removed from libssl.
* Fix a problem introduced in freezero() conversion and usejsg2017-05-111-2/+2
| | | | | | | | | | sizeof(struct) not sizeof(pointer). otto@ points out that on OpenBSD currently freezero() would have still zeroed the entire allocation, but this is not documented behaviour and may change in future. ok tom@
* use freezero() instead of memset/explicit_bzero + free. Substantiallyderaadt2017-05-021-3/+2
| | | | | | | | | | reduces conditional logic (-218, +82). MOD_EXP_CTIME_MIN_CACHE_LINE_WIDTH cache alignment calculation bn/bn_exp.c wasn'tt quite right. Two other tricky bits with ASN1_STRING_FLAG_NDEF and BN_FLG_STATIC_DATA where the condition cannot be collapsed completely. Passes regress. ok beck
* Send the function codes from the error functions to the bit bucket,beck2017-01-291-12/+10
| | | | | | as was done earlier in libssl. Thanks inoguchi@ for noticing libssl had more reacharounds into this. ok jsing@ inoguchi@
* Rename EVP_aead_chacha20_poly1305() to EVP_aead_chacha20_poly1305_old()jsing2016-04-281-11/+11
| | | | | | | and replace with EVP_aead_chacha20_poly1305_ietf(). The IETF version will become the standard version. Discussed with many.
* Use the correct iv and counter when decrypting the ciphertext forjsing2016-04-131-4/+4
| | | | EVP_aead_chacha20_poly1305_ietf().
* Fix typo in comment of previous commit: "that that".reyk2015-11-021-3/+3
|
* Add EVP_aead_chacha20_poly1305_ietf() - The informational RFC 7539,reyk2015-11-021-18/+111
| | | | | | | | | "ChaCha20 and Poly1305 for IETF Protocols", introduced a modified AEAD construction that is incompatible with the common style that has been already used in TLS with EVP_aead_chacha20_poly1305(). The IETF version also adds a constant (salt) that is prepended to the nonce. OK mikeb@ jsing@
* Correct spelling of OPENSSL_cleanse.jsing2015-09-101-2/+2
| | | | ok miod@
* Replace remaining CRYPTO_memcmp() calls with timingsafe_memcmp().jsing2015-06-201-2/+2
| | | | ok doug@ deraadt@
* Explicitly include <openssl/opensslconf.h> in every file that referencesjsing2014-07-101-3/+5
| | | | | | | | | an OPENSSL_NO_* define. This avoids relying on something else pulling it in for us, plus it fixes several cases where the #ifndef OPENSSL_NO_XYZ is never going to do anything, since OPENSSL_NO_XYZ will never defined, due to the fact that opensslconf.h has not been included. This also includes some miscellaneous sorting/tidying of headers.
* Switch to the ISC licensed versions of these files, which Google has madejsing2014-06-211-47/+13
| | | | | | available via boringssl. ok deraadt@
* tags as requested by miod and teduderaadt2014-06-121-0/+1
|
* Implement an improved version of the EVP AEAD API. Thejsing2014-05-261-29/+33
| | | | | | | | | | | | | | | | EVP_AEAD_CTX_{open,seal} functions previously returned an ssize_t that was overloaded to indicate success/failure, along with the number of bytes written as output. This change adds an explicit *out_len argument which is used to return the number of output bytes and the return value is now an int that is purely used to identify success or failure. This change effectively rides the last libcrypto crank (although I do not expect there to be many users of the EVP AEAD API currently). Thanks to Adam Langley for providing the improved code that this diff is based on. ok miod@
* Convert OPENSSL_malloc stuff back to intrinsics, a few were missedbeck2014-05-221-2/+2
| | | | | as new stuff was brought in. ok miod@
* Use C99 initialisers for the AEAD struct.jsing2014-05-151-9/+9
|
* KNF.jsing2014-05-151-70/+67
|
* Add a ChaCha20-Poly1305 AEAD EVP implementation to libcrypto, from Adamjsing2014-05-151-0/+261
Langley's Chromium OpenSSL patches. ok miod@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-04-29 07:21:09 +0000