Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NCC audit fixes #907

Closed
wants to merge 2 commits into from
Closed

NCC audit fixes #907

wants to merge 2 commits into from

Conversation

fjarri
Copy link
Contributor

@fjarri fjarri commented Jul 8, 2023

(Audit is not finished, so this is a draft)

  • Check for r=0 in addition to s=0 in try_sign_prehashed() - even though it's very unlikely, but so is s=0, and FIPS186-5 requires this check.

@@ -213,7 +213,7 @@ impl SignPrimitive<Secp256k1> for Scalar {
// Compute 𝒔 as a signature over 𝒓 and 𝒛.
let s = k_inv * (z + (r * self));

if s.is_zero().into() {
if s.is_zero().into() || r.is_zero().into() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opened RustCrypto/signatures#730 which hopefully clarifies both the logic and documentation around checks that r and s are non-zero.

Note that these checks are part of the invariant of the ecdsa::Signature type and the constructors return an error if either component is zero.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's actually a lot of duplicated logic there which would be nice to merge somehow.

But I would disagree that these checks are redundant just because Signature::from_scalars implements them. It is a part of the public API, and it makes sense for it to preserve that invariant too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's actually a lot of duplicated logic there which would be nice to merge somehow.

I think I'd like to extract some functions like ecdsa::hazmat::{sign_raw, verify_raw}... the duplication largely exists to implement low-S normalization, but if it can call a low-level function we don't need to duplicate the rest of the implementation. See also #908 for a verification-side analogue of this problem (where the generic implementation is being used, but low-S normalization is no longer honored)

But I would disagree that these checks are redundant just because Signature::from_scalars implements them. It is a part of the public API, and it makes sense for it to preserve that invariant too.

If it makes the code easier to audit I'm fine with it.

@@ -40,7 +40,7 @@ pub use elliptic_curve::ecdh::diffie_hellman;

use crate::{AffinePoint, Secp256k1};

/// NIST P-256 Ephemeral Diffie-Hellman Secret.
/// secp256k1 Ephemeral Diffie-Hellman Secret.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opened #929 with this fix individually

@tarcieri
Copy link
Member

With #929 opened I think we can close this. All of the required checks are upstream in the ecdsa crate.

@fjarri in some other PR I think you saw how it's impossible to return an ecdsa::Signature where r or s are zero, though I don't remember that PR offhand

@fjarri
Copy link
Contributor Author

fjarri commented Sep 14, 2023

I think this check is invalidated by the latest changes anyway, and happens in ecdsa crate now. Closing.

@fjarri fjarri closed this Sep 14, 2023
@fjarri fjarri deleted the audit-fixes branch December 31, 2023 18:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants