summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/evp/evp_enc.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Use more consistent naming for some files in evptb2023-12-291-687/+0
| | | | | | | | | | | | | EVP_Digest{Init,Update,Final}() move from digest.c to evp_digest.c which will become the home of all things related to EVP_MD{,_CTX} handling. EVP_Cipher{Init,Update,Final}() move from evp_enc.c to evp_cipher.c which will become the home of all things related to EVP_CIPHER{,_CTX} handling. EVP_Encode{Init,Update,Final}() move from encode.c to evp_encode.c which already is the home of EVP_ENCODE_CTX_{new,free}(). discussed with jsing
* EVP_CipherInit(): remove cleanup calltb2023-12-261-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | There is a bizarre EVP_CIPHER_CTX_cleanup() call in EVP_CipherInit() leading to a subtle behavior difference with EVP_CipherInit_ex(). The history is that before EVP_CIPHER_CTX was made opaque, a context would often live on the stack (hello, MariaDB) and the EVP_CIPHER_CTX_cleanup() call was in fact an EVP_CIPHER_CTX_init() which just zeroes out the struct. The problem with doing this is that on context reuse there could be data hanging off it, causing leaks. Attempts were made to clean up things in EVP_CipherFinal*(), but that broke applications reaching into the context afterward, so they were removed again. Later on, opacity allowed changing the _init() to a _cleanup() since EVP_CIPHER_CTX could no longer live on the stack, so it would no longer contain garbage. I have to correct myself: it would no longer contain stack garbage. Now: EVP_CipherInit_ex() does some extra dances to preserve the AES key wrap flag, which is cleared unconditionally in EVP_CipherInit(). That's annoying to document and very likely never going to be an issue in the wild: you'd need to do key wrap and then use the same context for use with a cipher that does not allow key wrap for this to make a difference. This way, all our EVP_{Cipher,Decrypt,Encrypt}*_ex() functions are now trivially wrapped by their non-_ex() versions. ok jsing
* EVP_CipherInit_ex() merge two code pathstb2023-12-261-9/+4
| | | | | | | | Clean up the cipher context unconditionally if the cipher is being set. This allows doing the dance to retain the key wrap flag only once and makes it more obvious that allocating the cipher data doesn't leak. suggested by/ok jsing
* Use more consistent order for Init/Update/Finaltb2023-12-231-17/+17
| | | | | | | Consistently implement the _ex() version after the non-extended versions, First Cipher Init/Update/Final, then Encrypt, then Decrypt. This only switches the order of CipherFinal{,_ex} and move the DecryptInit* down, so they are no longer somewhere in the middle of the Encrypt* functions.
* Remove two no longer necessary reminderstb2023-12-221-3/+1
| | | | | I guess I'm getting old. Next time I'll have to add a reminder not to forget to remove the reminder.
* Add length checks for partial_lentb2023-12-221-6/+7
| | | | | | | These remove a few more potential out-of-bounds accesses and ensure in particular that the padding is between 1 and block_size (inclusive). ok joshua jsing
* Simplify some logic in EVP_EncryptInit_ex()tb2023-12-221-24/+28
| | | | | | | | | | Pull up the EVP_R_NO_CIPHER_SET check that was hidden somewhere down in the middle of the function. Handle the reuse case outside of the big non-NULL cipher case for now. This looks a bit odd but relies on the invariant that cipher_data is only set if the cipher is set. It will be reworked in a subsequent commit. ok jsing
* evp_enc: make some flag checks explicittb2023-12-221-4/+4
| | | | ok joshua jsing
* Remove some superfluous parenthesestb2023-12-211-3/+3
|
* Rename impl into enginetb2023-12-201-4/+4
|
* Rename inl to in_len throughout the filetb2023-12-201-32/+32
|
* Rename outl into out_len throughout the filetb2023-12-201-32/+32
|
* Tweak a comment a bittb2023-12-201-3/+3
|
* Remove block_mask from EVP_CIPHER_CTXtb2023-12-201-5/+14
| | | | | | | The block mask is only used in EVP_{De,En}cryptUpdate(). There's no need to hang it off the EVP_CIPHER_CTX since it is easy to compute and validate. ok joshua jsing
* Improve local variable namestb2023-12-201-29/+29
| | | | | | | Rename the slightly awkward buf_offset into partial_len and rename buf_avail into partial_needed to match. suggested by jsing
* Rename buf_len into partial_len in EVP_CIPHER_CTXtb2023-12-201-9/+9
| | | | suggested by jsing
* Clean up EVP_DecryptFinal_ex()tb2023-12-201-32/+35
| | | | | | | | | | Rework the code to use the usual variable names, return early if we have block size 1 and unindent the remainder of the code for block sizes 8 and 16. Rework the padding check to be less acrobatic and copy the remainder of the plain text into out using memcpy() rather than a for loop. input/ok jsing
* Clean up EVP_EncryptFinal_ex()tb2023-12-201-16/+13
| | | | | | | This switches to the variable names used in other functions, adds a reminder to add a missing length check and uses memset for the padding. ok jsing
* Simplify EVP_DecryptUpdate() a bittb2023-12-201-26/+28
| | | | | | | | | | | | | | | This time the block size is called b and there's some awful length fiddling with fix_len, which until recently also served as store for the return value for do_cipher()... If we land on a block boundary, we keep the last block decrypted and don't count it as part of the output. So in the next call we need to feed it back in. Feeding it back in counts as output written this time around, so instead of remembering that we need to adjust outl, keep a tally of the bytes written. This way we can also do some overflow and underflow checking. ok jsing
* EVP_EncryptUpdate(): make block_size and block_mask consttb2023-12-161-3/+3
| | | | suggested by millert
* First cleanup pass over EVP_EncryptUpdate()tb2023-12-161-36/+37
| | | | | | | | | Use more sensible variable names in order to make the logic a bit easier to follow. The variables may be renamed in a later pass. Unindent a block that was squeezed too much to the right and make a few minor stylistic tweaks. ok jsing
* Implement and use a do_cipher() wrappertb2023-12-161-59/+63
| | | | | | | | | | | | | | | Instead of using five different idioms for eight callers of the do_cipher() method in EVP_{Decrypt,Encrypt}{Update,Final_ex}(), wrap the API insanity in an evp_cipher() function that calls do_cipher() as appropriate depending on the EVP_CIPH_FLAG_CUSTOM_CIPHER being set or not. This wrapper has the usual OpenSSL calling conventions. There is one complication in EVP_EncryptUpdate() in the case a previous call wrote only a partial buffer. In that case, the evp_cipher() call is made twice and the lengths have to be added. Add overflow checks and only set outl (the number of bytes written) to out on success. ok jsing
* Document EVP_Cipher() in codetb2023-12-151-1/+13
| | | | | | | | | | | | | | | EVP_Cipher() is an implementation detail of EVP_Cipher{Update,Final}(). Behavior depends on EVP_CIPH_FLAG_CUSTOM_CIPHER being set on ctx->cipher. If the flag is set, do_cipher() operates in update mode if in != NULL and in final mode if in == NULL. It returns the number of bytes written to out (which may be 0) or -1 on error. If the flag is not set, do_cipher() assumes properly aligned data and that padding is handled correctly by the caller. Most do_cipher() methods will silently produce garbage and succeed. Returns 1 on success, 0 on error. ok jsing
* Move EVP_Cipher() from evp_lib.c to evp_enc.ctb2023-12-151-1/+8
| | | | | | | | EVP_Cipher() is a dangerous thin wrapper of the do_cipher() method set on the EVP_CIPHER_CTX's cipher. It implements (part of) the update and final step of the EVP_Cipher* API. Its behavior is nuts and will be documented in a comment in a subsequent commit. schwarze has a manpage diff that will fix the incorrect documentation.
* Remove misuse warnings for EVP_*Final()tb2023-12-031-12/+1
| | | | | | | | | | | | | | They make no sense. These are thin wrappers of EVP_*Final_ex() and behave exactly the same way. The minor behavior difference of Init and Init_ex is likely a historical artefact of this abomination of an API. Deprecation of the Init functions was recently removed from the manpage. The only reason to prefer the _ex versions over the normal versions is ENGINE. This is no longer an argument. The warnings were added in an attempt at adding automatic cleanup. This broke stuff and was therefore backed out. The warnings remained. discussed with schwarze
* Unify various EVP_*{Update,Final}*() wrapperstb2023-12-011-18/+10
| | | | | | The correct way of wrapping foo() is 'int ret; ret = foo(); return ret;' because 'return foo();' would be too simple... Also unify branching from EVP_Cipher* into EVP_Encrypt* EVP_Decrypt*.
* Ignore ENGINE at the API boundarytb2023-11-291-4/+4
| | | | | | | | This removes the remaining ENGINE members from various internal structs and functions. Any ENGINE passed into a public API is now completely ignored functions returning an ENGINE always return NULL. ok jsing
* Unifdef OPENSSL_NO_ENGINE in libcryptotb2023-11-191-54/+1
| | | | | | | This is mechanical apart from a few manual edits to avoid doubled empty lines. ok jsing
* Check for negative IV lengthtb2023-11-181-12/+15
| | | | | | | | | | | | A recent change in EVP_CIPHER_CTX_iv_length() made it possible in principle that this function returns -1. This can only happen for an incorrectly set up EVP_CIPHER. Still it is better form to check for negative lengths before stuffing it into a memcpy(). It would probably be desirable to cap the iv_length to something large enough. This can be done another time. ok beck
* EVP_CipherInit(): use EVP_CIPHER_CTX_cleanup()tb2023-09-101-3/+3
| | | | | | | | | | | | | | | | Before EVP_CIPHER_CTX was opaque, callers could pass an uninitialized ctx into EVP_CipherInit() and calling EVP_CIPHER_CTX_cleanup() on such a ctx would end in tears. The only way to initialize a ctx is by way of EVP_CIPHER_CTX_new(), on which we can call EVP_CIPHER_CTX_cleanup() and avoid silly leaks on ctx reuse. This also allows some simplifications in the documentation. There are more changes of this kind that should be done all over libcrypto. They will be tackled in subsequent commits. "makes a lot of sense" schwarze ok jsing
* Unbreak the namespace build after a broken mk.conf and tool misfire hadbeck2023-07-071-26/+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/+26
| | | | | | (part 2 of commit) ok jsing@
* Make the cleanup() method return an int againtb2023-03-011-1/+2
| | | | | | | | | 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
* spelling fixes; from paul tagliamontejmc2022-12-261-2/+2
| | | | | | | i removed the arithmetics -> arithmetic changes, as i felt they were not clearly correct ok tb
* 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-5/+8
| | | | | | | Now that EVP_CIPHER is opaque, stop pretending that EVP_CIPHER cleanup can fail. ok tb@
* Expand the looney M_do_cipher macro.jsing2022-09-041-11/+9
| | | | Only change in generated assembly is due to line numbers.
* Do not pass input length <= 0 to the cipher handlerstb2022-07-261-11/+17
| | | | | | | | | | Input length < 0 is an error and input length == 0 can result in strange effects in some ciphers, except in CCM mode, which is extra special. Based on OpenSSL 420cb707 by Matt Caswell and Richard Levitte found by & ok jsing
* Pull in fix for EVP_CipherUpdate() overflow from OpenSSL.tb2021-02-181-1/+23
| | | | | | | | | | | | | | ok inoguchi commit 6a51b9e1d0cf0bf8515f7201b68fb0a3482b3dc1 Author: Matt Caswell <matt@openssl.org> Date: Tue Feb 2 17:17:23 2021 +0000 Don't overflow the output length in EVP_CipherUpdate calls CVE-2021-23840 Reviewed-by: Paul Dale <pauli@openssl.org>
* Use calloc() when allocating cipher_data.jsing2019-04-141-5/+5
| | | | | | Avoids use of uninitialised memory. ok tb@
* Annotate a future improvement.jsing2019-04-141-1/+2
|
* Avoid potential double-frees following EVP_CIPHER_CTX_copy().jsing2019-04-141-4/+17
| | | | | | | | | | | In the case of a cipher with a custom copy control, if that control fails we may still have pointers that we do not own in the previously copied cipher data. Avoid potential double-frees by zeroing and freeing the copied cipher data in this case. Issue reported by Guido Vranken. ok tb@
* Provide EVP_aes_{128,192,256}_wrap(). This is a compatibletb2019-03-171-2/+8
| | | | | | | | | | | | | implementation based on the one in OpenSSL 1.0.2r which is still freely licensed. The functions are undocumented in OpenSSL. To use them, one needs to set the undocumented EVP_CIPHER_CTX_FLAG_WRAP_ALLOW flag on the EVP_CIPHER_CTX. resolves #505 ok jsing
* make ENGINE_finish() succeed on NULL and simplify callers as intb2018-04-141-5/+2
| | | | | | | | | | | OpenSSL commit 7c96dbcdab9 by Rich Salz. This cleans up the caller side quite a bit and reduces the number of lines enclosed in #ifndef OPENSSL_NO_ENGINE. codesearch.debian.net shows that almost nothing checks the return value of ENGINE_finish(). While there, replace a few nearby 'if (!ptr)' with 'if (ptr == NULL)'. ok jsing, tested by & ok inoguchi
* Provide EVP_CIPHER_CTX_reset().jsing2018-02-171-17/+25
| | | | Rides previous minor bump.
* GNU ld has prefixed the contents of .gnu.warning.SYMBOL sectionstb2017-11-281-4/+4
| | | | | | | | with "warning: " since 2003, so the messages themselves need not contain the prefix anymore. From Scott Cheloha ok jca, deraadt
* Send the function codes from the error functions to the bit bucket,beck2017-01-291-35/+24
| | | | | | as was done earlier in libssl. Thanks inoguchi@ for noticing libssl had more reacharounds into this. ok jsing@ inoguchi@
* back out calls to EVP_CIPHER_CTX_cleanup() in EVP_Cipher/Encrypt/DecryptFinalbcook2016-09-091-4/+1
| | | | | Software that refers to ctx after calling Final breaks with these changes. revert parts of 1.31 and 1.32
* include <sys/types.h> to get <sys/cdefs.h> instead (for __warn_references)bcook2016-09-041-2/+2
| | | | corrected by deraadt@ / guenther@
* include <sys/cdefs.h> for portablebcook2016-09-041-1/+3
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-04-28 08:54:08 +0000