summaryrefslogtreecommitdiffstats
path: root/providers
AgeCommit message (Collapse)Author
2023-08-04When exporting/importing decoded keys do not use 0 as selectionTomas Mraz
When decoding 0 as the selection means to decode anything you get. However when exporting and then importing the key data 0 as selection is not meaningful. So we set it to OSSL_KEYMGMT_SELECT_ALL to make the export/import function export/import everything that we have decoded. Fixes #21493 Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Todd Short <todd.short@me.com> (Merged from https://github.com/openssl/openssl/pull/21519) (cherry picked from commit 2acb0d363c0032b5b97c4f6596609f40bd7d842f)
2023-08-04Avoid exporting bogus (empty) data if empty selection is usedTomas Mraz
This is already correct in the rsa_kmgmt.c but other implementations are wrong. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Todd Short <todd.short@me.com> (Merged from https://github.com/openssl/openssl/pull/21519) (cherry picked from commit 1ae4678cebaa13604c0f31bdf2c64cd28bdaf287)
2023-08-01Don't add the msblob/pvk decoders if they're not suitableMatt Caswell
msblob only decodes public/private keys (not just params). pvk only decodes private keys. If the requested selection doesn't intersect with the above then don't consider those decoders. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/21603) (cherry picked from commit 6207f2b657b5ba1823681b49c7c34c619da0dd00)
2023-08-01make updateMatt Caswell
Reviewed-by: Tomas Mraz <tomas@openssl.org> Release: yes
2023-08-01Copyright year updatesMatt Caswell
Reviewed-by: Tomas Mraz <tomas@openssl.org> Release: yes
2023-07-14Do not ignore empty associated data with AES-SIV modeTomas Mraz
The AES-SIV mode allows for multiple associated data items authenticated separately with any of these being 0 length. The provided implementation ignores such empty associated data which is incorrect in regards to the RFC 5297 and is also a security issue because such empty associated data then become unauthenticated if an application expects to authenticate them. Fixes CVE-2023-2975 Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/21384) (cherry picked from commit c426c281cfc23ab182f7d7d7a35229e7db1494d9)
2023-06-30Do not use stitched AES-GCM implementation on PPC32Tomas Mraz
The implementation is not usable there at all. Fixes #21301 Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/21312)
2023-06-16fips: use tsan counter instead of tsan_add to incrementPauli
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/21199) (cherry picked from commit ff934cfdc85a7b8ddb4bdebf9ab68d518bf68b7f)
2023-06-15fips: update DSA security check to fix legacy verify strengthsPauli
Refer SP 800-131Ar2 table 2: https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final Fixes #21185 Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/21186) (cherry picked from commit 71cf587ea21c1422640847e358019a51806d2811)
2023-06-14fips: use memory ordering rather than locksPauli
The FIPS provider accesses it's current state under lock. This is overkill, little or no synchronisation is actually required in practice (because it's essentially a read only setting). Switch to using TSAN operations in preference. Fixes #21179 Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/21187) (cherry picked from commit 8e9ca334528e0a923c4deb0af250a60510974be0)
2023-06-10Set RC4 defines on libcrypto/liblegacyTomas Mraz
Also add missing prototype for rc4_md5_enc. Fixes #21150 Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/21153) (cherry picked from commit 58e8af4cecd23dbea2e6b061ab68190b38d64145)
2023-06-06Cast the argument to unsigned char when calling isdigit()Michael Baentsch
Fixes #21123 Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/21127) (cherry picked from commit 8229874476cc2955e6947cf6d3fee09e13b8c160)
2023-05-30make updateTomas Mraz
Reviewed-by: Richard Levitte <levitte@openssl.org> Release: yes
2023-05-30Update copyright yearTomas Mraz
Reviewed-by: Richard Levitte <levitte@openssl.org> Release: yes
2023-05-23If oaep_md is not initialized, correctly initialize itDmitry Belyavskiy
Fixes #20993 Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20994) (cherry picked from commit c5aa719502f1ef456b27347e5f7b15c07817da4e)
2023-05-19Update hkdf.c to avoid potentially vulnerable code patternNicky Mouha
The expression "if (a+b>c) a=c-b" is incorrect if "a+b" overflows. It should be replaced by "if (a>c-b) a=c-b", which avoids the potential overflow and is much easier to understand. This pattern is the root cause of CVE-2022-37454, a buffer overflow vulnerability in the "official" SHA-3 implementation. It has been confirmed that the addition in https://github.com/openssl/openssl/blob/master/providers/implementations/kdfs/hkdf.c#L534 cannot overflow. So this is only a minor change proposal to avoid a potentially vulnerable code pattern and to improve readability. More information: https://github.com/github/codeql/pull/12036#issuecomment-1466056959 CLA: trivial Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20990) (cherry picked from commit 56a51b5a1ecd54eadc80bed4bfe5044a340787c1)
2023-05-12provider: return error if buf too small when getting ec pubkey paramYi Li
Fixes #20889 There was an incorrect value passed to EC_POINT_point2oct() for the buffer size of the param passed-in. Added testcases. Signed-off-by: Yi Li <yi1.li@intel.com> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20890) (cherry picked from commit 91070877adb905f51eb4b19b730d42fc257bae13)
2023-03-29Declare FIPS option functions in their own headerPauli
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/20521) (cherry picked from commit 30ab774770a7e8547b0d6363b63a73cc80f33a7b)
2023-03-29DRBG: restrict the digests that can be used with HMAC and Hash DRBGs.Pauli
According to FIP 140-3 IG D.R: https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf Outside of FIPS, there remains no restriction other than not allowing XOF digests. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/20521) (cherry picked from commit f553c0f0dd24f037f31d971a99a1ffe7a11f64e6)
2023-03-29fips: rework the option handling codePauli
Add option for restricting digests available to DRBGs. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/20521) (cherry picked from commit 83ccf81b1dd8886d54c570354ef8c532af4c514f)
2023-03-15Segmentation fault in parent rng cleanupafshinpir
CLA: trivial When `cleanup_entropy()` is called to cleanup parent by calling provided `OSSL_FUNC_rand_clear_seed_fn` method, incorrect random context is passed to the method. So accessing that context creates a segmentation fault. Parent context should be passed rather than DRBG's own context. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20454) (cherry picked from commit 6d45fd47f4849c8dc55b8dd5fa1e1b8a158774a0)
2023-03-15Updated `rsa_has()` for correct validationafshinpir
CLA: trivial In RSA, `(n,e)` and `(n,d)` identify public key and private key. Modulus `n` is the common part. So I updated `rsa_has()` to validate these pairs correctly. `OSSL_KEYMGMT_SELECT_KEYPAIR` is common part for both public and private key, so I changed it to check `n` of RSA and for `OSSL_KEYMGMT_SELECT_PUBLIC_KEY`, `e` is checked. Before this change, if `selection` was `OSSL_KEYMGMT_SELECT_PRIVATE_KEY` and only `e` and `d` was in the RSA structure, the function returns 1 while it was incorrect. Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20455) (cherry picked from commit a3207163ef3d30658a41a9c9e3750ca4c5b16677)
2023-03-15Fix size_t/int mismatch in cms_ec.c and rsa_sig.cTomas Mraz
Fixes #20435 Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20457) (cherry picked from commit 559e078d94f1213318105b03f4e88b848fc28314)
2023-03-14make updateMatt Caswell
Reviewed-by: Tomas Mraz <tomas@openssl.org> Release: yes
2023-03-14Update copyright yearMatt Caswell
Reviewed-by: Tomas Mraz <tomas@openssl.org> Release: yes (Merged from https://github.com/openssl/openssl/pull/20508)
2023-03-07fips: Use salt >= 16 bytes in PBKDF2 selftestClemens Lang
NIST SP 800-132 [1] section 5.1 says "[t]he length of the randomly-generated portion of the salt shall be at least 128 bits", which implies that the salt for PBKDF2 must be at least 16 bytes long (see also Appendix A.2.1). The FIPS 140-3 IG [2] section 10.3.A requires that "the lengths and the properties of the Password and Salt parameters, as well as the desired length of the Master Key used in a CAST shall be among those supported by the module in the approved mode." As a consequence, the salt length in the self test must be at least 16 bytes long for FIPS 140-3 compliance. Switch the self test to use the only test vector from RFC 6070 that uses salt that is long enough to fulfil this requirement. Since RFC 6070 does not provide expected results for PBKDF2 with HMAC-SHA256, use the output from [3], which was generated with python cryptography, which was tested against the RFC 6070 vectors with HMAC-SHA1. [1]: https://doi.org/10.6028/NIST.SP.800-132 [2]: https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf [3]: https://github.com/brycx/Test-Vector-Generation/blob/master/PBKDF2/pbkdf2-hmac-sha2-test-vectors.md Signed-off-by: Clemens Lang <cllang@redhat.com> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20429) (cherry picked from commit 451cb23c41c90d5a02902b3a77551aa9ee1c6956)
2023-03-07Add option to FIPS module to enforce EMS check during KDF TLS1_PRF.slontis
Fixes #19989 Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20241) (cherry picked from commit 50ea5cdcb735916591e35a04c1f5a659bf253ddc)
2023-02-28Fix incomplete error check on RSA_public_decrypt()ndossche
According to the documentation and my analysis tool RSA_public_decrypt() can return -1 on error, but this is not checked. Fix it by changing the error condition. CLA: trivial Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20250) (cherry picked from commit 8195e59986031f6f33e2569551d771904433fa04)
2023-02-22Revert "Put EdDSA back as approved algorithms."Pauli
This reverts commit 09627a8ceb69e19d2855b36228f44a3660af177a. NIST isn't allowing EdDSA at this stage after all, so flag it as not FIPS approved in the FIPS provider. Guidance for FIPS 140-3 is expected later this month: The use of EdDSA still remains non-approved. Before the FIPS 186-5 and SP 800-186 algorithms / curves can be used in the approved mode, the CMVP will need to do (at least) the following: * Incorporate FIPS 186-5 and SP 800-186 into SP 800-140C/D; * Update IG 10.3.A to incorporate self-test requirements for the new algorithms/curves. * Write a new IG on this transition to clarify the issues raised in this thread and elsewhere and provide a clear transition schedule. The CMVP is working on all three of these items and hope to have drafts public by the end of March. Since security relevant changes are not permitted for new 140-2 submissions, and under the assumption that this transition away from FIPS 186-4 algorithms will be 'soft' and not move modules to the historical list, we do not plan on writing 140-2 guidance for this transition. It seems unlikely that all of these requirements will be completed before we submit. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Hugo Landau <hlandau@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20343) (cherry picked from commit 759ab5984eb981f2dd165979a7abb950ddad81ae)
2023-02-20kbkdf: Fix kbkdf_dup function pointer typeClemens Lang
kbkdf_dup should use the appropriate type OSSL_FUNC_kdf_dupctx_fn. Signed-off-by: Clemens Lang <cllang@redhat.com> Reviewed-by: Todd Short <todd.short@me.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20314) (cherry picked from commit 344d3b326d573a0eeb5dcbffa643bc06f00023ed)
2023-02-08des: prevent error when using two key triple DES with a random keyPauli
Two key 3DES only sets two keys and the random generation errors out if fewer than three keys are required. It shouldn't. Fixes #20212 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20224) (cherry picked from commit 587e0407803af330c0b04238fcbce78521ce35d7)
2023-02-08Put EdDSA back as approved algorithms.Pauli
With FIPS 186-5 being published, these can again be validated. https://csrc.nist.gov/publications/detail/fips/186/5/final Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from https://github.com/openssl/openssl/pull/20219) (cherry picked from commit 09627a8ceb69e19d2855b36228f44a3660af177a)
2023-02-07Do not create DSA keys without parameters by decoderTomas Mraz
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org>
2023-02-07Prevent creating DSA and DH keys without parameters through importTomas Mraz
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org>
2023-01-30ChaCha20-Poly1305 no longer supports truncated IV's.slontis
Fixes #20084 In the 3.0 provider implementation the generic code that handles IV's only allows a 12 byte IV. Older code intentionally added the ability for the IV to be truncated. As this truncation is unsafe, the documentation has been updated to state that this in no longer allowed. The code has been updated to produce an error when the iv length is set to any value other than 12. NOTE: It appears that this additional padding may have originated from the code which uses a 12 byte IV, that is then passed to CHACHA which zero pads it to 16 bytes. Note that legacy behaviour in e_chacha20_poly1305.c has not been updated. Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20151) (cherry picked from commit a01152370676e7e11fb461cff8628eb50fa41b81)
2023-01-24Put X25519 and X448 back as approved algorithmsPauli
CMVP's answer when questioned about this being: X448 and X25519 uses Curve448 and Curve25519, respectfully, within an ECDH scheme. Therefore, it is possible for a key agreement scheme that uses Curve448 and Curve25519 to be used in the approved mode and be viewed as an allowed algorithm if requirements of Scenario X2 of IG D.8 and IG A.2 are met (or Scenario 3 of D.F and IG C.A for FIPS 140-3). The use of EdDSA in the approved mode is not permitted until FIPS 186-5 is published and part of CMVP guidance. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Hugo Landau <hlandau@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20079) (cherry picked from commit 8948b5749410084ed1dfabf17a90df65efcf0f82)
2023-01-17Fix potential NULL pointer dereferenceJuergen Christ
In EC key generation, if allocation of struct ec_gen_ctx fails, values provided by parameters are copied into the context at represented by a NULL pointer. To fix this, prevent copy if allocation fails. Signed-off-by: Juergen Christ <jchrist@linux.ibm.com> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20055) (cherry picked from commit 235ef96049dbe337a3c3c5d419dacbb5a81df1b3)
2023-01-16s390x: Fix keccak xofs via CPACFJuergen Christ
CPACF does not directly support xofs. Emulate this by using single block operations on an empty input block. Fixes: affc070aabc9 ("s390x: Optimize kmac") Signed-off-by: Juergen Christ <jchrist@linux.ibm.com> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19983) (cherry picked from commit 76aa4f3ac0d76e58f2111cbf87ae7f25c8766190)
2023-01-13fips: make EdDSA unapproved for FIPSPauli
Likewise for the related ECX key exchanges. NIST is mandating this until FIPS 186-5 is finalised. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/20020) (cherry picked from commit 9fa553247874728cee8ca0ece9aaed476eb0f303)
2023-01-12SSKDF with KMAC should return SIZE_MAX when EVP_KDF_CTX_get_kdf_size()slontis
is used. Fixes #19934 The existing code was looking for the digest size, and then returned zero. The example code in EVP_KDF-SS.pod has been corrected to not use a digest. Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19935) (cherry picked from commit e8add4d379075a6daef2591edd830297d469b9f4)
2022-12-22Change HKDF to alloc the info buffer.slontis
Fixes #19909 I have enforced a maximum bound still but it is much higher. Note also that TLS13 still uses the 2048 buffer size. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19923) (cherry picked from commit e8115bd1654d5cd7718109679b2047ca573083a8)
2022-12-22ec_kmgmt.c: check the return of BN_CTX_get() in time.xkernel
If x and y are all NULL, then it is unnecessary to do subsequent operations. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19905) (cherry picked from commit 467b0492c1e597857b30b91ed72605387aa9825b)
2022-12-21make updateTomas Mraz
Reviewed-by: Hugo Landau <hlandau@openssl.org> Release: yes
2022-12-21Update copyright yearTomas Mraz
Reviewed-by: Hugo Landau <hlandau@openssl.org> Release: yes (Merged from https://github.com/openssl/openssl/pull/19944)
2022-12-16Add KMAC support to KBKDF.slontis
Now that ACVP test vectors exist, support has been added for this mode. See https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-108r1.pdf Note that the test vectors used fairly large values for the input key and the context, so the contraints for these has been increased from 256 to 512 bytes. Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19916) (cherry picked from commit 211c47ca1b1ac129dcee59d383cae44e36532bb9)
2022-12-09signature: Clamp PSS salt len to MD lenClemens Lang
FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection 5.5 "PKCS #1" says: "For RSASSA-PSS […] the length (in bytes) of the salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of the hash function output block (in bytes)." Introduce a new option RSA_PSS_SALTLEN_AUTO_DIGEST_MAX and make it the default. The new value will behave like RSA_PSS_SALTLEN_AUTO, but will not use more than the digest length when signing, so that FIPS 186-4 is not violated. This value has two advantages when compared with RSA_PSS_SALTLEN_DIGEST: (1) It will continue to do auto-detection when verifying signatures for maximum compatibility, where RSA_PSS_SALTLEN_DIGEST would fail for other digest sizes. (2) It will work for combinations where the maximum salt length is smaller than the digest size, which typically happens with large digest sizes (e.g., SHA-512) and small RSA keys. J.-S. Coron shows in "Optimal Security Proofs for PSS and Other Signature Schemes. Advances in Cryptology – Eurocrypt 2002, volume 2332 of Lecture Notes in Computer Science, pp. 272 – 287. Springer Verlag, 2002." that longer salts than the output size of modern hash functions do not increase security: "For example,for an application in which at most one billion signatures will be generated, k0 = 30 bits of random salt are actually sufficient to guarantee the same level of security as RSA, and taking a larger salt does not increase the security level." Signed-off-by: Clemens Lang <cllang@redhat.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (cherry picked from commit 6c73ca4a2f4ea71f4a880670624e7b2fdb6f32da) (Merged from https://github.com/openssl/openssl/pull/19862)
2022-12-01make updateTomas Mraz
Reviewed-by: Matt Caswell <matt@openssl.org> Release: yes
2022-12-01Update copyright yearTomas Mraz
Reviewed-by: Matt Caswell <matt@openssl.org> Release: yes (Merged from https://github.com/openssl/openssl/pull/19803)
2022-11-29Honor OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT as set and default to ↵Nicola Tuveri
UNCOMPRESSED Originally the code to im/export the EC pubkey was meant to be consumed only by the im/export functions when crossing the provider boundary. Having our providers exporting to a COMPRESSED format octet string made sense to avoid memory waste, as it wasn't exposed outside the provider API, and providers had all tools available to convert across the three formats. Later on, with #13139 deprecating the `EC_KEY_*` functions, more state was added among the params imported/exported on an EC provider-native key (including `OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT`, although it did not affect the format used to export `OSSL_PKEY_PARAM_PUB_KEY`). Finally, in #14800, `EVP_PKEY_todata()` was introduced and prominently exposed directly to users outside the provider API, and the choice of COMPRESSED over UNCOMPRESSED as the default became less sensible in light of usability, given the latter is more often needed by applications and protocols. This commit fixes it, by using `EC_KEY_get_conv_form()` to get the point format from the internal state (an `EC_KEY` under the hood) of the provider-side object, and using it on `EVP_PKEY_export()`/`EVP_PKEY_todata()` to format `OSSL_PKEY_PARAM_PUB_KEY`. The default for an `EC_KEY` was already UNCOMPRESSED, and it is altered if the user sets `OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT` via `EVP_PKEY_fromdata()`, `EVP_PKEY_set_params()`, or one of the more specialized methods. For symmetry, this commit also alters `ec_pkey_export_to()` in `crypto/ec/ec_ameth.c`, part of the `EVP_PKEY_ASN1_METHOD` for legacy EC keys: it exclusively used COMPRESSED format, and now it honors the conversion format specified in the EC_KEY object being exported to a provider when this function is called. Expand documentation about `OSSL_PKEY_PARAM_PUB_KEY` and mention the 3.1 change in behavior for our providers. Fixes #16595 Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19681)
2022-11-23Fix AES-GCM on Power 8 CPUsTomas Mraz
Properly fallback to the default implementation on CPUs missing necessary instructions. Fixes #19163 Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19182) (cherry picked from commit 9ab6b64ac856157a31a54c0d12207c2338bfa8e2)
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-02 06:16:35 +0000