Have DigestSigner/DigestVerifier take Digest instance #17
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is needed forcompatibility with ed25519-dalek's Ed25519ph: https://docs.rs/ed25519-dalek/1.0.0-pre.1/ed25519_dalek/struct.Keypair.html#method.sign_prehashed Until const generics land, this API feels a lot cleaner to me. It gets all the `GenericArray` crap out of the way. It's also misuse resistant in that it ensures the prehashing is done by the relevant hash function, as opposed to the user being able to pass in arbitrary values. There's a potential attack if a verifier accidentally accepts a raw value which isn't the output of a hash function which could allow an attacker to forge signatures: https://twitter.com/pwuille/status/1063582706288586752
Merged
Closed
tarcieri
added a commit
to RustCrypto/traits
that referenced
this pull request
Sep 9, 2022
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.,
tarcieri
added a commit
to RustCrypto/traits
that referenced
this pull request
Sep 9, 2022
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.
tarcieri
added a commit
to RustCrypto/traits
that referenced
this pull request
Sep 9, 2022
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is needed for compatibility with ed25519-dalek's Ed25519ph:
https://docs.rs/ed25519-dalek/1.0.0-pre.1/ed25519_dalek/struct.Keypair.html#method.sign_prehashed
Until const generics land, this API feels a lot cleaner to me. It gets all the
GenericArraycrap out of the way.It's also misuse resistant in that it ensures the prehashing is done by the relevant hash function, as opposed to the user being able to pass in arbitrary values. There's a potential attack if a verifier accidentally accepts a raw value which isn't the output of a hash function which could allow an attacker to forge signatures:
https://twitter.com/pwuille/status/1063582706288586752