-
Notifications
You must be signed in to change notification settings - Fork 198
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
signature: add hazmat-preview
feature
#1099
Conversation
Adds a `hazmat` module gated under a newly added `hazmat-preview` feature which calls out the relevant functionality as subject to change with minor versions. It adds the following traits: - `PrehashSigner` - `PrehashVerifier` These APIs accept the digest to be signed/verified as a raw byte slice. This comes with potential misuses like failing to use a cryptographically secure hash function as the `prehash`, which could enable existential forgeries of signatures, hence gating it under a `hazmat-preview` feature and placing it in a `hazmat` module. Note that we previously explored APIs like this for `DigestSigner`. They were removed in RustCrypto/signatures#17 due to the afforementioned misuse potential. However, these APIs are occasionally needed for implementing protocols that use special rules for computing hashes (e.g. EIP-712 structured hashes), or for implementing things like network signing services which want to accept a prehash of a message to be signed rather than the full message (to cut down on network bandwidth). The traits accept a byte slice `prehash`, which permits multiple lengths and allows the implementation to decide which lengths are valid. This makes it possible for e.g. ECDSA implementations to automatically truncate message prehashes which are larger than the field size.
a74710b
to
75426c9
Compare
/// | ||
/// Allowed lengths are algorithm-dependent and up to a particular | ||
/// implementation to decide. | ||
fn try_sign_prehash(&self, prehash: &[u8]) -> Result<S, Error>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about a few different alternatives to prehash: &[u8]
(i.e. a byte slice), including:
- Adding a const generic parameter to the trait, which would permit overlapping impls for different sizes
- Using
generic-array
While both of those are worth considering, algorithms like DSA and RSASSA-PKCS#1v15/PSS both currently use num-bigint-dig
with heap-allocated bignums that don't know their own size at a type level.
So I think a slice really is the only option that's general enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could introduce two separate methods: array and slice based. The latter would have a default impl in terms of the former. The mentioned algorithm implementations would overwrite the slice-based method and implement the array-based one using slice-based.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only algorithm that would benefit for now is ECDSA, and that would need generic-array
so the implementation in the ecdsa
crate can be generic around field sizes.
However, using the slice-based API means we can implement hash truncation / zero padding in one place, which would make it easier to support some exotic combinations of curve and hash functions, such as ECDSA/P-256 with SHA384, or ECDSA/P-384 with SHA-256.
It would probably be nice to add custom derive support for |
@lumag FYI, if we merge these, you may want to impl them for the RSA signature keys |
@tarcieri I think I should abstain from implementing it for now. Let's not complicate unreleased dependencies anymore. Not to mention that it adds no direct benefit, as one can use old API to operate on raw (prehashed) data. |
@lumag sure, it'd be great if we could wrap up the Note that the intended use case of these traits is abstracting across signing implementations where the |
agree |
Adds "hazmat" trait impls to `SigningKey` and `VerifyingKey` respectively which allow computing signatures over raw message digests. See RustCrypto/traits#1099. The implementation allows digests which are shorter or longer than the field size of the curve, using zero-padding if the digest is too short, and truncating if it's too long. The minimum digest size is set to half of the curve's field size.
Adds "hazmat" trait impls to `SigningKey` and `VerifyingKey` respectively which allow computing signatures over raw message digests. See RustCrypto/traits#1099. The implementation allows digests which are shorter or longer than the field size of the curve, using zero-padding if the digest is too short, and truncating if it's too long. The minimum digest size is set to half of the curve's field size.
Adds "hazmat" trait impls to `SigningKey` and `VerifyingKey` respectively which allow computing signatures over raw message digests. See RustCrypto/traits#1099. The implementation allows digests which are shorter or longer than the field size of the curve, using zero-padding if the digest is too short, and truncating if it's too long. The minimum digest size is set to half of the curve's field size.
Adds a
hazmat
module gated under a newly addedhazmat-preview
feature which calls out the relevant functionality as subject to change with minor versions.It adds the following traits:
PrehashSigner
PrehashVerifier
These APIs accept the digest to be signed/verified as a raw byte slice. This comes with potential misuses like failing to use a cryptographically secure hash function as the
prehash
, which could enable existential forgeries of signatures, hence gating it under ahazmat-preview
feature and placing it in ahazmat
module.Note that we previously explored APIs like this for
DigestSigner
. They were removed in RustCrypto/signatures#17 due to the afforementioned misuse potential.However, these APIs are occasionally needed for implementing protocols that use special rules for computing hashes (e.g. EIP-712 structured hashes), or for implementing things like network signing services which want to accept a prehash of a message to be signed rather than the full message (to cut down on network bandwidth).
The traits accept a byte slice
prehash
, which permits multiple lengths and allows the implementation to decide which lengths are valid. This makes it possible for e.g. ECDSA implementations to automatically truncate message prehashes which are larger than the field size.