summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/evp (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* const correct aesni_{128,256}_cbc_hmac_sha1_ciphertb2024-01-081-3/+3
|
* const-correct r4_hmac_md5_ciphertb2024-01-071-2/+2
|
* Convert the remaining legacy ciphers to C99 initializerstb2024-01-075-76/+90
| | | | | | No change in the generated aarch64 assembly apart from line number changes. ok jsing
* Improve EVP_CIPHER_{get,set}_asn1_iv()tb2024-01-071-25/+26
| | | | | | | | | Use iv_len for the variables storing the IV length, formerly l and j. Remove use of the unnecessary variable i and unindent the whole mess. Some return values are fishy. That will be addressed in subsequent commits. ok jsing
* EVP_PKEY_asn1_find_str() tweakstb2024-01-051-4/+3
| | | | | Switch i to a size_t and improve a flag check. Part of an earlier diff that was ok jsing but were lost when I reworked the diff.
* evp_key.c: Remove more unnecessary parenthesestb2024-01-051-7/+6
|
* Minor tweaks in EVP_read_pw_string_min()tb2024-01-051-4/+4
| | | | | Remove unnecessary parentheses and use a better place to break an overlong line.
* Plug a leak in EVP_read_pw_string_min()tb2024-01-051-9/+14
| | | | | | | Use an error exit that frees the ui in case the UI_add_* fail. Also add a few empty lines for readability. ok joshua
* Disable EVP_PKEY_meth_* extensibilitytb2024-01-041-46/+7
| | | | | | | | | | This removes the global pkey_app_methods stack that was never cleaned up and makes EVP_PKEY_meth_add0() always fail and push an error on the stack. EVP_PKEY_meth_find() can now walk the list of PKEY_METHODs forward and things become a bit cleaner. It's still all way more complicated than it needs to be... ok jsing
* Remove unused app_data from EVP_CIPHERtb2024-01-0415-84/+15
| | | | | | | | The EVP_CIPHER structs are static const data that the library returns when you call EVP_aes_128_cbc(), for example. It makes no sense whatsoever to hang user data off such a struct, but it's been there since forever. ok jsing
* Clean up EVP_PKEY_asn1_get0_info() a bittb2024-01-041-14/+16
| | | | | Use better variable names without silly p prefix and use explicit checks against NULL.
* Clean up EVP_PKEY_asn1_find_str()tb2024-01-041-9/+18
| | | | | | | | | Use slightly better argument and variable names, do not pointlessly try to match a string of negative length < -1, use a size_t for the strlen() and preserve the logic that allows lookup by a string fragment rather than a full string. ok jsing
* Simplify EVP_PKEY_asn1_find()tb2024-01-041-33/+9
| | | | | | | | | EVP_PKEY_asn1_find() finds the EVP_PKEY_ASN1_METHOD underlying the method or alias with nid (or, rather, pkey_id) passed in. Now that we have the base method stored in a pointer, we can return that method after a simple lookup of said nid (or, rather, pkey_id). ok jsing
* Replace .pkey_base_id with a .base_method pointertb2024-01-042-5/+5
| | | | | | | | | | | | | | | | Every EVP_PKEY_ASN1_METHOD is either an ASN.1 method or an alias. As such it resolves to an underlying ASN.1 method (in one step). This information can be stored in a base_method pointer in allusion to the pkey_base_id, which is the name for the nid (aka pkey_id aka type) of the underlying method. For an ASN.1 method, the base method is itself, so the base method is set as a pointer to itself. For an alias it is of course a pointer to the underlying method. Then obviously ameth->pkey_base_id is the same as ameth->base_method->pkey_id, so rework all ASN.1 methods to follow that. ok jsing
* Split ameth arrays into individual methodstb2024-01-041-14/+21
| | | | | | | | | | | | For some reason DSA, GOST, and RSA had their ASN.1 methods stored in an array. This is clumsy and the only benefit is that one saves a few externs in p_lib.c. They were also arranged by ascending NID because of bsearch() madness. Split them up and arrange the methods by name, which is much saner and simpler. ok jsing
* Improve length checks for oiv and ivtb2024-01-041-4/+5
| | | | | | | | | | There are two unsigned char arrays of size EVP_MAX_IV_LENGTH to store the IVs of block ciphers. In most modes, only iv is used, but in some modes iv is modified and oiv is used to store the original IV. At the moment nothing enforces that they are of the same length. Therefore make sure the correct one or both are checked before writing to or reading from them. ok miod
* Improve order in ancient CMS helperstb2024-01-031-25/+25
| | | | | | | First came EVP_CIPHER_param_to_asn1() which wraps EVP_CIPHER_set_asn1_iv() which was implemented last. Then came EVP_CIPHER_asn1_to_param() wrapping EVP_CIPHER_get_asn1_iv(). Move each param function below the iv function it wraps.
* Move a t to the right place in a commenttb2024-01-021-2/+2
|
* Match struct order for the EVP_CIPHER_CTX accessorstb2024-01-021-69/+73
| | | | | | This isn't great since the struct is ordered in about the silliest way imaginable, but it is better than it was before. Bringing order into this mess is harder than solving a Rubik's cube.
* Move down EVP_CIPHER_CTX accessors expose EVP_CIPHER internalstb2024-01-021-38/+42
| | | | | These confusingly named getters were added "for convenience" in 1.1. They fit best next to the EVP_CIPHER API.
* Move the trivial EVP_CIPHER getters downtb2024-01-021-31/+35
| | | | | They are now below the CMS ASN.1 IV stuff, but above the EVP_CIPHER_meth* API, which are setters, in a way.
* Simplify EVP_CIPHER_{asn1_to_param,parma_to_asn1}()tb2024-01-021-17/+13
| | | | There's no need for a ret variable and else if/else
* Move the EVP_CIPHER API that only exists for CMS/legacy a bit downtb2024-01-021-121/+125
|
* sm4: more NULL misspellingstb2024-01-021-4/+4
|
* Two spellings of key length are enoughtb2024-01-021-6/+7
| | | | | | The API is called EVP_CIPHER_CTX_set_key_length() it has an argument called keylen and, the EVP_CIPHER_CTX's member is called key_len. One of the three is trivial to adjust, so do it.
* Rename the poor outlier EVP_CIPHER *e into *ciphertb2024-01-021-3/+3
|
* Better variable names in EVP_CIPHER_type()tb2024-01-021-7/+8
| | | | | The EVP_CIPHER *ctx (yes) is renamed to cipher, otmp becomes an aobj. Change two !ptr to ptr == NULL checks.
* Consistently use ctx for an EVP_CIPHER_CTXtb2024-01-021-36/+36
| | | | Not c (which is most of the time an EVP_CIPHER) or a (?!).
* Fix bounds check in EVP_PKEY_CTX_get_keygen_info()tb2024-01-011-2/+2
| | | | | | | | | Replace > with >= for the upper array bound to disallow a 4 byte overread. For RSA you can read the padding mode and for DH past the DH_PKEY_CTX. Unfortunately, Ruby thought it important to use this, so we can't kill it easily. ok miod
* Remove EVP_PKEY's save_type membertb2024-01-012-6/+2
| | | | | | | This was only used to avoid an ameth lookup in EVP_PKEY_set_type(), a micro-optimization that was removed in p_lib.c r1.48. ok jsing
* Some Australians don't like voids eithertb2023-12-301-3/+3
|
* Move the EVP_PKEY_asn1_* API that will stay to evp/p_lib.ctb2023-12-292-6/+256
| | | | | | | | Most of these functions are only called from this file internally apart from the pem_str lookups from pem/. In the next major bump we can then remove asn/ameth_lib.c. Also move EVP_PKEY_ASN1_METHOD to evp_local.h. While this is used to dispatch to various ASN.1 decoding routines, it doesn't fit into asn1/ at all.
* Zap some whitespacetb2023-12-291-2/+2
|
* Move the EVP_MD block size accessor downtb2023-12-291-7/+11
| | | | | | This way all the EVP_MD accessors are in the order of the struct fields. Well, arguably the EVP_MD_meth* should come first, but they are scheduled to go meet the dodo.
* Move the EVP_MD_CTX flag accessors up a bittb2023-12-291-19/+19
| | | | This way the accessors are sorted the same way as the struct.
* Hoist EVP_MD_CTX accessors to after EVP_MD_CTX_ctrltb2023-12-291-63/+62
| | | | | | | This way the file has EVP_Digest*, then EVP_MD_CTX new/free/clean, then ctrl then the EVP_MD_CTX accessors, then the EVP_MD accessors and finally the EVP_MD_meth stuff and the order of things starts making a wee bit of sense.
* Move init/reset next to cleanuptb2023-12-291-13/+13
| | | | | | This way new/free aka create/destroy are next to each other. reset/cleanup are the same thing and init will join the club after some other fixing because two APIs that do the exact same thing aren't enough.
* Move the copy/copy_ex stuff down below the new/free/clear messtb2023-12-291-63/+64
|
* Merge the EVP_CIPHER_meth_* API into evp_cipher.ctb2023-12-292-186/+175
|
* Merge the remainder of evp_lib.c into evp_cipher.ctb2023-12-292-365/+298
|
* Move the middle part of evp_lib.c to evp_digest.ctb2023-12-292-205/+205
| | | | | These are ~200 lines of EVP_MD API that separated two parts of the file dedicated to EVP_CIPHER thingies.
* Use more consistent naming for some files in evptb2023-12-293-3/+3
| | | | | | | | | | | | | 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
* Move EVP_PKEY_assign() a bit up and tweak it slightlytb2023-12-251-10/+10
| | | | ok jsing
* Rename a few ret into pkeytb2023-12-251-28/+29
|
* Rework EVP_PKEY_set_type{,_str}()tb2023-12-251-34/+27
| | | | | | | | | | | | | These two functions previously wrapped a pkey_set_type() helper, which was an utter mess because of ENGINE. With the long awaited departure of ENGINE, this function became a lot simpler. A further simplification is obtained by not doing the optimization to avoid an ameth lookup: this requires walking a list of 11 ameths. We should consider bsearch()... With this gone and a saner implementation of EVP_PKEY_free_it(), we can implement these functions with a dozen lines of code each. ok jsing
* Rework EVP_PKEY_free()tb2023-12-251-11/+7
| | | | | | | | Use pkey instead of x, remove the pointless variable i, no need to check for NULL before sk_X509_ATTRIBUTE_pop_free(), switch to freezero() to leave fewer invalid pointers around. ok jsing
* Move EVP_PKEY_free() up next to evp_pkey_free_pkey_ptr()tb2023-12-251-19/+19
| | | | ok jsing
* Fix EVP_PKEY_up_ref() - must have hit ^X somehowtb2023-12-251-2/+2
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-20 15:56:14 +0000