Ec check named curve parameters #8555

slontis · 2019-03-22T00:58:22Z

Checklist

documentation is added or updated
tests are added or updated

dlegaultbbry · 2019-03-22T10:56:38Z

crypto/ec/ec_check.c

+    return 0;
+}
+
 int EC_GROUP_check(const EC_GROUP *group, BN_CTX *ctx)


Shouldn't the new function above be added somewhere in the EC check functions so that it's called when either calling EVP_PKEY_public_check, EVP_PKEY_check or EVP_PKEY_param_check?

It could go into EVP_PKEY_param_check() for FIPS mode (when that exists) since only approved NIST named curves are allowed in that mode. I dont know that this check should be done if custom curves are allowed (i.e non FIPS mode).

romen

Sorry for the delay in reviewing this, it took longer than expected!

First of all, I want to say thank you @slontis for working on this, and for including from the start appropriate unit testing!

It looks great, but I have a few comments which warrant a bit of discussion and some changes before approval.

crypto/ec/ec_curve.c

crypto/ec/ec_lcl.h

crypto/ec/ec_curve.c

test/ectest.c

slontis · 2019-03-28T21:40:14Z

The test failures are all due to the issue discussed above:
i.e: EC_GROUP_new_curve_GFp() selects the method table EC_GFp_mont_method() OR EC_GFp_nist_method().
ec_group_new_from_data() choses the custom method (if there is one) which is EC_GFp_nistz256_method).
As all checks are based on ec_point_is_compat() which checks if the methods are the same, there will be no match found in the table.

Not sure what the most elegant solution to this is currently.

romen

A few more points to discuss!

apps/ecparam.c

crypto/ec/ec_curve.c

crypto/ec/ec_lib.c

crypto/ec/ec_mult.c

test/ectest.c

romen · 2019-03-31T18:15:44Z

@slontis I worked a bit on this feature and I have two patches for test/ectest.c: would you like to review them and consider including them in this PR?

I have a fork of your ec_check_named_curve branch at https://github.com/romen/openssl/commits/ec_check_named_curve :

romen@c83a1f4

EC_GROUP_set_curve() might fail for arbitrary params

Setting arbitrary p, a or b with EC_GROUP_set_curve() might fail
for some EC_GROUPs, depending on the internal EC_METHOD
implementation, hence the block of tests verifying that
EC_GROUP_check_named_curve() fails when any of the curve parameters is
changed is modified to run only if the previous EC_GROUP_set_curve()
call succeeds.

ERR_set_mark() and ERR_pop_to_mark() are used to avoid littering the
thread error stack with unrelated errors happened during
EC_GROUP_set_curve().
romen@1b78a65

Separate the lookup test

This fixes the "verifying the alias" case.
Actually, while working on it, I realized that conceptually we were
testing the 2 different behaviours of EC_GROUP_check_named_curve() at
the same time, and actually not in the proper way.

I think it's fair to assume that overwriting the curve name for an
existing group with NID_undef could lead to the unexpected behaviour
we were observing and working around.
Thus I decided to separate the lookup test in a dedicated simpler test
that does what the documentation of EC_GROUP_check_named_curve()
suggests: the lookup functionality is meant to find a name for a group
generated with explicit parameters.

In case an alternative alias is returned by the lookup instead of the
expected nid, to avoid doing comparisons between EC_GROUPs with
different EC_METHODs, the workaround is to retrieve the ECPARAMETERS
of the "alias group" and create a new explicit parameters group to use
in EC_GROUP_cmp().

romen · 2019-03-31T18:22:46Z

We should also keep in mind, before the final review, that we should run the extended tests.

You can trigger those more time consuming tests by making sure the last commit contains in the message body the following line:

[extended tests]

crypto/ec/ec_curve.c

romen

LGTM, just a few nits and a sidenote.

Could you please add an empty commit containing [extended tests] in the message body?
I wish to see the results of those tests before approving.

crypto/ec/ec_lib.c

doc/man3/EC_GROUP_copy.pod

doc/man1/ecparam.pod

crypto/ec/ec_curve.c

test/ectest.c

crypto/ec/ec_curve.c

doc/man3/EC_GROUP_copy.pod

slontis · 2019-04-02T02:09:22Z

Extended tests fail when running BoringSSL Tests.
#8634 shows that master is already broken. (by running with an empty commit)

romen

ok, assuming the BoringSSL breakage is unrelated (it really is difficult to be sure about what exactly is failing in the BoringSSL test recipe), this looks good to me.

Thanks for all your efforts on this and the other PRs @slontis !

Now we have to wait for at least one OCM reviewer to approve.

crypto/ec/ec_check.c

doc/man1/ecparam.pod

slontis · 2019-04-08T23:22:44Z

Can you review again please @mattcaswell

mattcaswell

Approved subject to a rebase

romen · 2019-04-09T11:49:07Z

@slontis you will now need to rebase on latest master due to the conflict on util/libcrypto.num. You can then force-push here for a last round of approvals before merge.

Setting arbitrary `p`, `a` or `b` with `EC_GROUP_set_curve()` might fail for some `EC_GROUP`s, depending on the internal `EC_METHOD` implementation, hence the block of tests verifying that `EC_GROUP_check_named_curve()` fails when any of the curve parameters is changed is modified to run only if the previous `EC_GROUP_set_curve()` call succeeds. `ERR_set_mark()` and `ERR_pop_to_mark()` are used to avoid littering the thread error stack with unrelated errors happened during `EC_GROUP_set_curve()`.

slontis · 2019-04-10T23:07:37Z

ping should be good now

romen

Formal re-approval after force-push.

mattcaswell

Reconfirm

romen · 2019-04-11T09:03:28Z

Thanks @mattcaswell , I'll proceed to merge!

Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #8555)

Setting arbitrary `p`, `a` or `b` with `EC_GROUP_set_curve()` might fail for some `EC_GROUP`s, depending on the internal `EC_METHOD` implementation, hence the block of tests verifying that `EC_GROUP_check_named_curve()` fails when any of the curve parameters is changed is modified to run only if the previous `EC_GROUP_set_curve()` call succeeds. `ERR_set_mark()` and `ERR_pop_to_mark()` are used to avoid littering the thread error stack with unrelated errors happened during `EC_GROUP_set_curve()`. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #8555)

This fixes the "verifying the alias" case. Actually, while working on it, I realized that conceptually we were testing the 2 different behaviours of `EC_GROUP_check_named_curve()` at the same time, and actually not in the proper way. I think it's fair to assume that overwriting the curve name for an existing group with `NID_undef` could lead to the unexpected behaviour we were observing and working around. Thus I decided to separate the lookup test in a dedicated simpler test that does what the documentation of `EC_GROUP_check_named_curve()` suggests: the lookup functionality is meant to find a name for a group generated with explicit parameters. In case an alternative alias is returned by the lookup instead of the expected nid, to avoid doing comparisons between `EC_GROUP`s with different `EC_METHOD`s, the workaround is to retrieve the `ECPARAMETERS` of the "alias group" and create a new explicit parameters group to use in `EC_GROUP_cmp()`. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #8555)

Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #8555)

romen · 2019-04-11T09:21:56Z

Thanks @slontis and everyone that gave feedback on this, I believe it was a very good discussion on top of a nice feature to add!

Squashed and merged to master with:

…n curves This commit includes a partial backport of openssl#8555 (commit 8402cd5) for which the main author is Shane Lontis <shane.lontis@oracle.com> Co-authored-by: Shane Lontis <shane.lontis@oracle.com>

Description ----------- Upon `EC_GROUP_new_from_ecparameters()` check if the parameters match any of the built-in curves. If that is the case, return a new `EC_GROUP_new_by_curve_name()` object instead of the explicit parameters `EC_GROUP`. This affects all users of `EC_GROUP_new_from_ecparameters()`: - direct calls to `EC_GROUP_new_from_ecparameters()` - direct calls to `EC_GROUP_new_from_ecpkparameters()` with an explicit parameters argument - ASN.1 parsing of explicit parameters keys (as it eventually ends up calling `EC_GROUP_new_from_ecpkparameters()`) A parsed explicit parameter key will still be marked with the `OPENSSL_EC_EXPLICIT_CURVE` ASN.1 flag on load, so, unless programmatically forced otherwise, if the key is eventually serialized the output will still be encoded with explicit parameters, even if internally it is treated as a named curve `EC_GROUP`. Before this change, creating any `EC_GROUP` object using `EC_GROUP_new_from_ecparameters()`, yielded an object associated with the default generic `EC_METHOD`, but this was never guaranteed in the documentation. After this commit, users of the library that intentionally want to create an `EC_GROUP` object using a specific `EC_METHOD` can still explicitly call `EC_GROUP_new(foo_method)` and then manually set the curve parameters using `EC_GROUP_set_*()`. Motivation ---------- This has obvious performance benefits for the built-in curves with specialized `EC_METHOD`s and subtle but important security benefits: - the specialized methods have better security hardening than the generic implementations - optional fields in the parameter encoding, like the `cofactor`, cannot be leveraged by an attacker to force execution of the less secure code-paths for single point scalar multiplication - in general, this leads to reducing the attack surface Check the manuscript at https://arxiv.org/abs/1909.01785 for an in depth analysis of the issues related to this commit. It should be noted that `libssl` does not allow to negotiate explicit parameters (as per RFC 8422), so it is not directly affected by the consequences of using explicit parameters that this commit fixes. On the other hand, we detected external applications and users in the wild that use explicit parameters by default (and sometimes using 0 as the cofactor value, which is technically not a valid value per the specification, but is tolerated by parsers for wider compatibility given that the field is optional). These external users of `libcrypto` are exposed to these vulnerabilities and their security will benefit from this commit. Related commits --------------- While this commit is beneficial for users using built-in curves and explicit parameters encoding for serialized keys, commit b783bee (and its equivalents for the 1.0.2, 1.1.0 and 1.1.1 stable branches) fixes the consequences of the invalid cofactor values more in general also for other curves (CVE-2019-1547). The following list covers commits in `master` that are related to the vulnerabilities presented in the manuscript motivating this commit: - d2baf88 [crypto/rsa] Set the constant-time flag in multi-prime RSA too - 311e903 [crypto/asn1] Fix multiple SCA vulnerabilities during RSA key validation. - b783bee [crypto/ec] for ECC parameters with NULL or zero cofactor, compute it - 724339f Fix SCA vulnerability when using PVK and MSBLOB key formats Note that the PRs that contributed the listed commits also include other commits providing related testing and documentation, in addition to links to PRs and commits backporting the fixes to the 1.0.2, 1.1.0 and 1.1.1 branches. This commit includes a partial backport of #8555 (commit 8402cd5) for which the main author is Shane Lontis. Responsible Disclosure ---------------------- This and the other issues presented in https://arxiv.org/abs/1909.01785 were reported by Cesar Pereida García, Sohaib ul Hassan, Nicola Tuveri, Iaroslav Gridin, Alejandro Cabrera Aldaya and Billy Bob Brumley from the NISEC group at Tampere University, FINLAND. The OpenSSL Security Team evaluated the security risk for this vulnerability as low, and encouraged to propose fixes using public Pull Requests. _______________________________________________________________________________ Co-authored-by: Shane Lontis <shane.lontis@oracle.com> (Backport from #9808) Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #9809)

Description ----------- Upon `EC_GROUP_new_from_ecparameters()` check if the parameters match any of the built-in curves. If that is the case, return a new `EC_GROUP_new_by_curve_name()` object instead of the explicit parameters `EC_GROUP`. This affects all users of `EC_GROUP_new_from_ecparameters()`: - direct calls to `EC_GROUP_new_from_ecparameters()` - direct calls to `EC_GROUP_new_from_ecpkparameters()` with an explicit parameters argument - ASN.1 parsing of explicit parameters keys (as it eventually ends up calling `EC_GROUP_new_from_ecpkparameters()`) A parsed explicit parameter key will still be marked with the `OPENSSL_EC_EXPLICIT_CURVE` ASN.1 flag on load, so, unless programmatically forced otherwise, if the key is eventually serialized the output will still be encoded with explicit parameters, even if internally it is treated as a named curve `EC_GROUP`. Before this change, creating any `EC_GROUP` object using `EC_GROUP_new_from_ecparameters()`, yielded an object associated with the default generic `EC_METHOD`, but this was never guaranteed in the documentation. After this commit, users of the library that intentionally want to create an `EC_GROUP` object using a specific `EC_METHOD` can still explicitly call `EC_GROUP_new(foo_method)` and then manually set the curve parameters using `EC_GROUP_set_*()`. Motivation ---------- This has obvious performance benefits for the built-in curves with specialized `EC_METHOD`s and subtle but important security benefits: - the specialized methods have better security hardening than the generic implementations - optional fields in the parameter encoding, like the `cofactor`, cannot be leveraged by an attacker to force execution of the less secure code-paths for single point scalar multiplication - in general, this leads to reducing the attack surface Check the manuscript at https://arxiv.org/abs/1909.01785 for an in depth analysis of the issues related to this commit. It should be noted that `libssl` does not allow to negotiate explicit parameters (as per RFC 8422), so it is not directly affected by the consequences of using explicit parameters that this commit fixes. On the other hand, we detected external applications and users in the wild that use explicit parameters by default (and sometimes using 0 as the cofactor value, which is technically not a valid value per the specification, but is tolerated by parsers for wider compatibility given that the field is optional). These external users of `libcrypto` are exposed to these vulnerabilities and their security will benefit from this commit. Related commits --------------- While this commit is beneficial for users using built-in curves and explicit parameters encoding for serialized keys, commit b783bee (and its equivalents for the 1.0.2, 1.1.0 and 1.1.1 stable branches) fixes the consequences of the invalid cofactor values more in general also for other curves (CVE-2019-1547). The following list covers commits in `master` that are related to the vulnerabilities presented in the manuscript motivating this commit: - d2baf88 [crypto/rsa] Set the constant-time flag in multi-prime RSA too - 311e903 [crypto/asn1] Fix multiple SCA vulnerabilities during RSA key validation. - b783bee [crypto/ec] for ECC parameters with NULL or zero cofactor, compute it - 724339f Fix SCA vulnerability when using PVK and MSBLOB key formats Note that the PRs that contributed the listed commits also include other commits providing related testing and documentation, in addition to links to PRs and commits backporting the fixes to the 1.0.2, 1.1.0 and 1.1.1 branches. This commit includes a partial backport of #8555 (commit 8402cd5) for which the main author is Shane Lontis. Responsible Disclosure ---------------------- This and the other issues presented in https://arxiv.org/abs/1909.01785 were reported by Cesar Pereida García, Sohaib ul Hassan, Nicola Tuveri, Iaroslav Gridin, Alejandro Cabrera Aldaya and Billy Bob Brumley from the NISEC group at Tampere University, FINLAND. The OpenSSL Security Team evaluated the security risk for this vulnerability as low, and encouraged to propose fixes using public Pull Requests. _______________________________________________________________________________ Co-authored-by: Shane Lontis <shane.lontis@oracle.com> (Backport from #9808) Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #9810)

Description ----------- Upon `EC_GROUP_new_from_ecparameters()` check if the parameters match any of the built-in curves. If that is the case, return a new `EC_GROUP_new_by_curve_name()` object instead of the explicit parameters `EC_GROUP`. This affects all users of `EC_GROUP_new_from_ecparameters()`: - direct calls to `EC_GROUP_new_from_ecparameters()` - direct calls to `EC_GROUP_new_from_ecpkparameters()` with an explicit parameters argument - ASN.1 parsing of explicit parameters keys (as it eventually ends up calling `EC_GROUP_new_from_ecpkparameters()`) A parsed explicit parameter key will still be marked with the `OPENSSL_EC_EXPLICIT_CURVE` ASN.1 flag on load, so, unless programmatically forced otherwise, if the key is eventually serialized the output will still be encoded with explicit parameters, even if internally it is treated as a named curve `EC_GROUP`. Before this change, creating any `EC_GROUP` object using `EC_GROUP_new_from_ecparameters()`, yielded an object associated with the default generic `EC_METHOD`, but this was never guaranteed in the documentation. After this commit, users of the library that intentionally want to create an `EC_GROUP` object using a specific `EC_METHOD` can still explicitly call `EC_GROUP_new(foo_method)` and then manually set the curve parameters using `EC_GROUP_set_*()`. Motivation ---------- This has obvious performance benefits for the built-in curves with specialized `EC_METHOD`s and subtle but important security benefits: - the specialized methods have better security hardening than the generic implementations - optional fields in the parameter encoding, like the `cofactor`, cannot be leveraged by an attacker to force execution of the less secure code-paths for single point scalar multiplication - in general, this leads to reducing the attack surface Check the manuscript at https://arxiv.org/abs/1909.01785 for an in depth analysis of the issues related to this commit. It should be noted that `libssl` does not allow to negotiate explicit parameters (as per RFC 8422), so it is not directly affected by the consequences of using explicit parameters that this commit fixes. On the other hand, we detected external applications and users in the wild that use explicit parameters by default (and sometimes using 0 as the cofactor value, which is technically not a valid value per the specification, but is tolerated by parsers for wider compatibility given that the field is optional). These external users of `libcrypto` are exposed to these vulnerabilities and their security will benefit from this commit. Related commits --------------- While this commit is beneficial for users using built-in curves and explicit parameters encoding for serialized keys, commit b783bee (and its equivalents for the 1.0.2, 1.1.0 and 1.1.1 stable branches) fixes the consequences of the invalid cofactor values more in general also for other curves (CVE-2019-1547). The following list covers commits in `master` that are related to the vulnerabilities presented in the manuscript motivating this commit: - d2baf88 [crypto/rsa] Set the constant-time flag in multi-prime RSA too - 311e903 [crypto/asn1] Fix multiple SCA vulnerabilities during RSA key validation. - b783bee [crypto/ec] for ECC parameters with NULL or zero cofactor, compute it - 724339f Fix SCA vulnerability when using PVK and MSBLOB key formats Note that the PRs that contributed the listed commits also include other commits providing related testing and documentation, in addition to links to PRs and commits backporting the fixes to the 1.0.2, 1.1.0 and 1.1.1 branches. This commit includes a partial backport of openssl#8555 (commit 8402cd5) for which the main author is Shane Lontis. Responsible Disclosure ---------------------- This and the other issues presented in https://arxiv.org/abs/1909.01785 were reported by Cesar Pereida García, Sohaib ul Hassan, Nicola Tuveri, Iaroslav Gridin, Alejandro Cabrera Aldaya and Billy Bob Brumley from the NISEC group at Tampere University, FINLAND. The OpenSSL Security Team evaluated the security risk for this vulnerability as low, and encouraged to propose fixes using public Pull Requests. _______________________________________________________________________________ Co-authored-by: Shane Lontis <shane.lontis@oracle.com> (Backport from openssl#9808)

Description ----------- Upon `EC_GROUP_new_from_ecparameters()` check if the parameters match any of the built-in curves. If that is the case, return a new `EC_GROUP_new_by_curve_name()` object instead of the explicit parameters `EC_GROUP`. This affects all users of `EC_GROUP_new_from_ecparameters()`: - direct calls to `EC_GROUP_new_from_ecparameters()` - direct calls to `EC_GROUP_new_from_ecpkparameters()` with an explicit parameters argument - ASN.1 parsing of explicit parameters keys (as it eventually ends up calling `EC_GROUP_new_from_ecpkparameters()`) A parsed explicit parameter key will still be marked with the `OPENSSL_EC_EXPLICIT_CURVE` ASN.1 flag on load, so, unless programmatically forced otherwise, if the key is eventually serialized the output will still be encoded with explicit parameters, even if internally it is treated as a named curve `EC_GROUP`. Before this change, creating any `EC_GROUP` object using `EC_GROUP_new_from_ecparameters()`, yielded an object associated with the default generic `EC_METHOD`, but this was never guaranteed in the documentation. After this commit, users of the library that intentionally want to create an `EC_GROUP` object using a specific `EC_METHOD` can still explicitly call `EC_GROUP_new(foo_method)` and then manually set the curve parameters using `EC_GROUP_set_*()`. Motivation ---------- This has obvious performance benefits for the built-in curves with specialized `EC_METHOD`s and subtle but important security benefits: - the specialized methods have better security hardening than the generic implementations - optional fields in the parameter encoding, like the `cofactor`, cannot be leveraged by an attacker to force execution of the less secure code-paths for single point scalar multiplication - in general, this leads to reducing the attack surface Check the manuscript at https://arxiv.org/abs/1909.01785 for an in depth analysis of the issues related to this commit. It should be noted that `libssl` does not allow to negotiate explicit parameters (as per RFC 8422), so it is not directly affected by the consequences of using explicit parameters that this commit fixes. On the other hand, we detected external applications and users in the wild that use explicit parameters by default (and sometimes using 0 as the cofactor value, which is technically not a valid value per the specification, but is tolerated by parsers for wider compatibility given that the field is optional). These external users of `libcrypto` are exposed to these vulnerabilities and their security will benefit from this commit. Related commits --------------- While this commit is beneficial for users using built-in curves and explicit parameters encoding for serialized keys, commit b783bee (and its equivalents for the 1.0.2, 1.1.0 and 1.1.1 stable branches) fixes the consequences of the invalid cofactor values more in general also for other curves (CVE-2019-1547). The following list covers commits in `master` that are related to the vulnerabilities presented in the manuscript motivating this commit: - d2baf88 [crypto/rsa] Set the constant-time flag in multi-prime RSA too - 311e903 [crypto/asn1] Fix multiple SCA vulnerabilities during RSA key validation. - b783bee [crypto/ec] for ECC parameters with NULL or zero cofactor, compute it - 724339f Fix SCA vulnerability when using PVK and MSBLOB key formats Note that the PRs that contributed the listed commits also include other commits providing related testing and documentation, in addition to links to PRs and commits backporting the fixes to the 1.0.2, 1.1.0 and 1.1.1 branches. This commit includes a partial backport of #8555 (commit 8402cd5) for which the main author is Shane Lontis. Responsible Disclosure ---------------------- This and the other issues presented in https://arxiv.org/abs/1909.01785 were reported by Cesar Pereida García, Sohaib ul Hassan, Nicola Tuveri, Iaroslav Gridin, Alejandro Cabrera Aldaya and Billy Bob Brumley from the NISEC group at Tampere University, FINLAND. The OpenSSL Security Team evaluated the security risk for this vulnerability as low, and encouraged to propose fixes using public Pull Requests. _______________________________________________________________________________ Co-authored-by: Shane Lontis <shane.lontis@oracle.com> (Backport from #9808) Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #9811)

slontis force-pushed the ec_check_named_curve branch from 1860468 to 7ec7505 Compare March 22, 2019 03:22

dlegaultbbry reviewed Mar 22, 2019

View reviewed changes

romen mentioned this pull request Mar 25, 2019

WIP : FIPS ECC related changes. (To be replaced by seperate PR's) #8524

Closed

2 tasks

romen self-assigned this Mar 25, 2019

romen added the branch: master Applies to master branch label Mar 25, 2019

romen reviewed Mar 27, 2019

View reviewed changes

romen reviewed Mar 29, 2019

View reviewed changes

romen mentioned this pull request Mar 29, 2019

EC_GROUP_cmp implementation vs documentation #8615

Open

slontis commented Mar 31, 2019

View reviewed changes

test/ectest.c Outdated Show resolved Hide resolved

slontis commented Mar 31, 2019

View reviewed changes

test/ectest.c Show resolved Hide resolved

romen reviewed Apr 1, 2019

View reviewed changes

crypto/ec/ec_curve.c Outdated Show resolved Hide resolved

romen mentioned this pull request Apr 1, 2019

Revise documentation for some EC_GROUP_* methods #8630

Closed

9 tasks

romen reviewed Apr 1, 2019

View reviewed changes

crypto/ec/ec_lib.c Outdated Show resolved Hide resolved

crypto/ec/ec_lib.c Outdated Show resolved Hide resolved

romen reviewed Apr 1, 2019

View reviewed changes

doc/man3/EC_GROUP_copy.pod Outdated Show resolved Hide resolved

slontis force-pushed the ec_check_named_curve branch from 90c9a7a to d9ce843 Compare April 1, 2019 12:06

FdaSilvaYY reviewed Apr 1, 2019

View reviewed changes

slontis force-pushed the ec_check_named_curve branch from d9ce843 to 4800723 Compare April 2, 2019 01:01

romen approved these changes Apr 3, 2019

View reviewed changes

romen added the approval: review pending This pull request needs review by a committer label Apr 3, 2019

mattcaswell requested changes Apr 4, 2019

View reviewed changes

crypto/ec/ec_check.c Show resolved Hide resolved

crypto/ec/ec_check.c Outdated Show resolved Hide resolved

doc/man1/ecparam.pod Outdated Show resolved Hide resolved

mattcaswell approved these changes Apr 9, 2019

View reviewed changes

romen removed the approval: review pending This pull request needs review by a committer label Apr 9, 2019

slontis and others added 2 commits April 10, 2019 10:08

added code to validate EC named curve parameters

d44fff5

slontis force-pushed the ec_check_named_curve branch from 1a07bed to 38039ed Compare April 10, 2019 00:18

romen requested a review from mattcaswell April 11, 2019 06:07

romen approved these changes Apr 11, 2019

View reviewed changes

mattcaswell approved these changes Apr 11, 2019

View reviewed changes

mattcaswell added the approval: done This pull request has the required number of approvals label Apr 11, 2019

levitte pushed a commit that referenced this pull request Apr 11, 2019

added code to validate EC named curve parameters

8402cd5

Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #8555)

levitte pushed a commit that referenced this pull request Apr 11, 2019

doc fixups

37f03b9

Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #8555)

romen closed this Apr 11, 2019

dlegaultbbry mentioned this pull request Jun 11, 2019

ec key validation checks updated #8564

Closed

2 tasks

romen mentioned this pull request Jun 26, 2019

Tests broken in master with enable-ec_nistp_64_gcc_128 #9251

Closed

romen mentioned this pull request Sep 8, 2019

[1.1.1-bp][ec] match built-in curves on EC_GROUP_new_from_ecparameters #9809

Closed

2 tasks

romen mentioned this pull request Sep 8, 2019

[1.1.0-bp][ec] match built-in curves on EC_GROUP_new_from_ecparameters #9810

Closed

2 tasks

romen mentioned this pull request Sep 9, 2019

[1.0.2-bp][ec] match built-in curves on EC_GROUP_new_from_ecparameters #9811

Closed

2 tasks

Uh oh!

Ec check named curve parameters #8555

Ec check named curve parameters #8555

Uh oh!

Conversation

slontis commented Mar 22, 2019

Checklist

Uh oh!

dlegaultbbry Mar 22, 2019

Choose a reason for hiding this comment

Uh oh!

slontis Mar 22, 2019

Choose a reason for hiding this comment

Uh oh!

romen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

slontis commented Mar 28, 2019

Uh oh!

romen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

romen commented Mar 31, 2019

Uh oh!

romen commented Mar 31, 2019

Uh oh!

Uh oh!

romen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

slontis commented Apr 2, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

romen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

slontis commented Apr 8, 2019

Uh oh!

mattcaswell left a comment

Choose a reason for hiding this comment

Uh oh!

romen commented Apr 9, 2019

Uh oh!

slontis commented Apr 10, 2019

slontis commented Apr 2, 2019 •

edited

Loading