Skip to content

O
openssl

btwise / openssl

通知 1
Star 0
Fork 0
O
openssl

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 10 8月, 2020 2 次提交
  3. 07 8月, 2020 1 次提交
  5. 19 6月, 2020 2 次提交
  7. 04 6月, 2020 1 次提交
  9. 29 5月, 2020 1 次提交
    • M
      Fail if we fail to fetch the EVP_KEYMGMT · b533510f
      由 Matt Caswell 提交于 
      If we failed to fetch an EVP_KEYMGMT then we were falling back to legacy.
This is because some algorithms (such as MACs and KDFs used via an old
style EVP_PKEY) have not been transferred to providers.

Unfortunately this means that you cannot stop some algorithms from being
used by not loading the provider.

For example if you wanted to prevent RSA from being used, you might expect
to just not load any providers that make it available. Unfortunately that
doesn't work because we simply fall back to legacy if we fail to fetch
the EVP_KEYMGMT.

Instead we should fail *unless* the key type is one of those legacy key
types that we have not transferred.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11826)
      b533510f
  11. 26 5月, 2020 1 次提交
    • S
      Update core_names.h fields and document most fields. · b8086652
      由 Shane Lontis 提交于 
      Renamed some values in core_names i.e Some DH specific names were changed to use DH instead of FFC.
Added some strings values related to RSA keys.
Moved set_params related docs out of EVP_PKEY_CTX_ctrl.pod into its own file.
Updated Keyexchange and signature code and docs.
Moved some common DSA/DH docs into a shared EVP_PKEY-FFC.pod.
Moved Ed25519.pod into EVP_SIGNATURE-ED25519.pod and reworked it.

Added some usage examples. As a result of the usage examples the following change was also made:
ec allows OSSL_PKEY_PARAM_USE_COFACTOR_ECDH as a settable gen parameter.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11610)
      b8086652
  13. 24 5月, 2020 1 次提交
    • R
      Re-introduce legacy EVP_PKEY types for provided keys · 5e5bc836
      由 Richard Levitte 提交于 
      EVP_PKEYs with provider side internal keys got the key type
EVP_PKEY_NONE.  This turned out to be too disruptive, so we try
instead to find a matching EVP_PKEY_ASN1_METHOD and use whatever
EVP_PKEY type it uses.

To make internal coding easier, we introduce a few internal macros to
distinguish what can be expected from a EVP_PKEY:

- evp_pkey_is_blank(), to detect an unassigned EVP_PKEY.
- evp_pkey_is_typed(), to detect that an EVP_PKEY has been assigned a
  type, which may be an old style type number or a EVP_KEYMGMT method.
- evp_pkey_is_assigned(), to detect that an EVP_PKEY has been assigned
  an key value.
- evp_pkey_is_legacy(), to detect that the internal EVP_PKEY key is a
  legacy one, i.e. will be handled via an EVP_PKEY_ASN1_METHOD and an
  EVP_PKEY_METHOD.
- evp_pkey_is_provided(), to detect that the internal EVP_PKEY key is
  a provider side one, i.e. will be handdled via an EVP_KEYMGMT and
  other provider methods.

This also introduces EVP_PKEY_KEYMGMT, to indicate that this EVP_PKEY
contains a provider side key for which there are no known
EVP_PKEY_ASN1_METHODs or EVP_PKEY_METHODs, i.e. these can only be
handled via EVP_KEYMGMT and other provider methods.

Fixes #11823
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11913)
      5e5bc836
  15. 14 5月, 2020 1 次提交
  17. 07 5月, 2020 1 次提交
    • S
      Remove gen_get_params & gen_gettable_params from keygen operation · 5e77b79a
      由 Shane Lontis 提交于 
      EVP_PKEY_CTX_gettable_params() was missing code for the keygen operation.
After adding it it was noticed that it is probably not required for this type, so instead
the gen_get_params and gen_gettable_params have been remnoved from the provider interface.
gen_get_params was only implemented for ec to get the curve name. This seems redundant
since normally you would set parameters into the keygen_init() and then generate a key.
Normally you would expect to extract data from the key - not the object that we just set up
to do the keygen.

Added a simple settable and gettable test into a test that does keygen.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11683)
      5e77b79a
  19. 28 4月, 2020 1 次提交
  21. 23 4月, 2020 1 次提交
  23. 17 4月, 2020 1 次提交
  25. 15 4月, 2020 4 次提交
  27. 11 4月, 2020 1 次提交
  29. 27 3月, 2020 1 次提交
  31. 26 3月, 2020 1 次提交
    • R
      EVP: Clarify the states of an EVP_PKEY · adc9f731
      由 Richard Levitte 提交于 
      EVP_PKEY is rather complex, even before provider side keys entered the
stage.
You could have untyped / unassigned keys (pk->type == EVP_PKEY_NONE),
keys that had been assigned a type but no data (pk->pkey.ptr == NULL),
and fully assigned keys (pk->type != EVP_PKEY_NONE && pk->pkey.ptr != NULL).

For provider side keys, the corresponding states weren't well defined,
and the code didn't quite account for all the possibilities.

We also guard most of the legacy fields in EVP_PKEY with FIPS_MODE, so
they don't exist at all in the FIPS module.

Most of all, code needs to adapt to the case where an EVP_PKEY's
|keymgmt| is non-NULL, but its |keydata| is NULL.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11375)
      adc9f731
  33. 21 3月, 2020 1 次提交
    • R
      EVP: fetch the EVP_KEYMGMT earlier · 4b9e90f4
      由 Richard Levitte 提交于 
      Instead of fetching the EVP_KEYMGMT in the init for every different
operation, do it when creating the EVP_PKEY_CTX.

This allows certain control functions to be called between the
creation of the EVP_PKEY_CTX and the call of the operation's init
function.

Use case: EVP_PKEY_CTX_set1_id(), which is allowed to be called very
early with the legacy implementation, this should still be allowed
with provider implementations.
Reviewed-by: NPaul Yang <kaishen.yy@antfin.com>
(Merged from https://github.com/openssl/openssl/pull/11343)
      4b9e90f4
  35. 15 3月, 2020 1 次提交
  37. 12 3月, 2020 2 次提交
  39. 04 3月, 2020 1 次提交
    • S
      Add Serializers for EC · f552d900
      由 Shane Lontis 提交于 
      Provide EC serializers for text, pem and der.

EC parameters use ANS1 'CHOICE' - which means they are more embedded than other parameters used by
other KEY types (which normally have a SEQUENCE at the top level).
For this reason the ANS1_STRING type that was being passed around has been changed to a void so that the
code can still be shared with EC.

The EC serializer only supports named curves currently.

NOTE the serializer code assumes PKCS8 format - if the older encode methods are needed they will need to be
added in another PR. (Probably when deserialization is considered).

EVP_PKEY_key_fromdata_init was changed from using a keypair selection to all bits of a key. A side effect of this was
that the very restrictive checks in the ecx code needed to be relaxed as it was assuming all selection flags were non
optional. As this is not the case for any other key the code has been modified.

Fixed a bug in legacy_ctrl_str_to_params() - "ecdh_cofactor_mode" was being incorrectly converted to the wrong keyname.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11107)
      f552d900
  41. 03 3月, 2020 1 次提交
  43. 29 2月, 2020 1 次提交
    • R
      Rethink the EVP_PKEY cache of provider side keys · 3c6ed955
      由 Richard Levitte 提交于 
      The role of this cache was two-fold:

1.  It was a cache of key copies exported to providers with which an
    operation was initiated.
2.  If the EVP_PKEY didn't have a legacy key, item 0 of the cache was
    the corresponding provider side origin, while the rest was the
    actual cache.

This dual role for item 0 made the code a bit confusing, so we now
make a separate keymgmt / keydata pair outside of that cache, which is
the provider side "origin" key.

A hard rule is that an EVP_PKEY cannot hold a legacy "origin" and a
provider side "origin" at the same time.
Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11148)
      3c6ed955
  45. 22 2月, 2020 1 次提交
  47. 21 2月, 2020 2 次提交
  49. 20 2月, 2020 1 次提交
  51. 19 2月, 2020 1 次提交
  53. 06 2月, 2020 1 次提交
  55. 05 2月, 2020 2 次提交
  57. 31 1月, 2020 1 次提交
  59. 29 1月, 2020 1 次提交
  61. 27 1月, 2020 1 次提交
  63. 23 1月, 2020 1 次提交