The rough outline of the algorithm is now completed. There is also a lack of test files and detailed modifications. Rust is too difficult. If there is something wrong, please point it out.

Expose the ability for the user to provide a prehashed hash-value for signing/verification. In rare cases, this is needed in other protocols. I have attempted to solve this with a custom Digest implementation, but eventually ran into (forced) finalization which affects the hash value.

In RSA, there are multiple schemes to sign/verify, mainly PKCS1 v1.5 and PSS (although others exists). I was looking at how to integrate signature into the RSA crate, and was a bit confused at the lack of a Padding argument or type in Signer/Verifier. Is the idea to implement Verifier on a type that is already aware of the padding scheme?

Adds a marker trait for Signature types computable as S(H(m)) where:

• S: signature algorithm
• H: hash (a.k.a. digest) function
• m: message

For signature types that implement this trait, a blanket impl of Signer will be provided for all types that impl signature::digest::Signer.

Hi,

I'm in a case where I need to verify a signature done on a whole &[u8] rather than a digest and I see that the relevant method is in the Verifier trait but it is not implemented anywhere in the dsa crate.

Is that an oversight or it is something just waiting for a contribution? Or am I missing something?

Regards,

In follow-up of discussion in #520: a minimal implementation for Signer and Verifier using SHA-256 for digests. The issue discusses possible options of introducing the OID, however this is not part of this implementation.

This PR contains a number of commits adding a set of traits for creating and verifying digital signatures.

I would suggest reviewing them commit-by-commit:

• 1f7efa6: Sign trait
• 9fd884c: Verify trait
• c438c2c: SignDigest and VerifyDigest
• f5e2db8: SignSha256, SignSha384, SignSha512, VerifySha256, VerifySha384, VerifySha512

All traits are bounded by Send + Sync to ensure signers and verifiers are thread safe. Libraries which provide access to HSMs will need to e.g. Mutex guard access to the underlying device.

This is simply a matter of iterating the hashing of self.v until sufficient output bytes have been produced.

This is necessary for the upcoming DSA implementation.

This is a fix for the issue I mentioned at https://github.com/RustCrypto/signatures/pull/534#discussion_r980613066. I believe the present implementation of prehash_to_field_bytes can't interop with OpenSSL (at least but should be the same for other crypto libraries)...

Description

prehash_to_field_bytes was zero-padding on the right of the byte sequence but this must be done on the left because the output is evaluated as a integer encoded in big-endian, and its integer representation should be stable regardless of sequence length.

This behavior is defined on various documents including RFC6979 Section 2.3.2., SEC 1 Section 2.3.8., NIST FIPS 186-4 Appendix C.2.1.

• https://datatracker.ietf.org/doc/html/rfc6979#section-2.3.2
• https://www.secg.org/sec1-v2.pdf
• https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.186-4.pdf

Verification

I used the following code to test signing with ecdsa crate and verify with OpenSSL:

use digest::{Digest, FixedOutput};
use ecdsa::signature::hazmat::PrehashSigner;
use elliptic_curve::sec1::ToEncodedPoint;
use openssl::nid::Nid;

const DATA: &str = "data to sign";

fn main() {
    let pkey = p384::SecretKey::random(&mut rand::thread_rng());
    let signing_key = ecdsa::SigningKey::from(&pkey);

    let digest = sha2::Sha256::digest(DATA);
    let signature = signing_key.sign_prehash(&digest).unwrap();

    //---------//

    let point_sec1 = pkey.public_key().to_encoded_point(false).to_bytes();
    let signature_der = signature.to_der().to_bytes();

    //---------//

    let mut ossl_bn_ctx = openssl::bn::BigNumContext::new().unwrap();
    let ossl_curve = openssl::ec::EcGroup::from_curve_name(Nid::SECP384R1).unwrap();
    let ossl_point =
        openssl::ec::EcPoint::from_bytes(&ossl_curve, &point_sec1, &mut ossl_bn_ctx).unwrap();
    let ossl_public_key = openssl::ec::EcKey::from_public_key(&ossl_curve, &ossl_point).unwrap();

    let ossl_signature = openssl::ecdsa::EcdsaSig::from_der(&signature_der).unwrap();
    assert!(ossl_signature.verify(&digest, &ossl_public_key).unwrap());
}

this patch fixes the crate not to fail the above code.

Implements the proposed breaking changes to the signature crate from https://github.com/RustCrypto/traits/pull/1141

Most notably the Signature trait has been replaced with a SignatureEncoding trait which permits an internally structured signature representation.

Presently the signing and verification key types are named SigningKey and VerifyKey. These are a bit inconsistent with each other grammatically. Per a Twitter straw poll, in particular people seem to dislike the current names.

Some potential alternatives:

• ecdsa::{SignKey, VerifyKey}
• ecdsa::{SigningKey, VerifyingKey}
• ecdsa::key::{Sign, Verify}

We're getting close to ready to cut a final release of signature v2.0.0: https://github.com/RustCrypto/traits/issues/1171

This is a tracking and discussion issue for any final changes before releasing the following:

• [ ] dsa v0.5.0
• [ ] ecdsa v0.15.0
• [ ] ed25519 v2.0.0

The r scalar component of an ECDSA signature is computed by lifting the affine x-coordinate of the curve point 𝑹 = 𝑘×𝑮 into an integer and reducing it modulo the curve's order into an element of the scalar field.

Though occurring infrequently (sometimes with a vanishingly small probability), this condition results in RecoveryId values of 2 or 3.

Presently only RecoveryId values of 0 or 1 are supported, and the others will result in an error when recovering the verifying key.

The main thing needed to implement this is access to R.y so we can check whether or not it's odd when computing the RecoveryId.

Related: https://github.com/zkcrypto/group/issues/30