chore(deps): bump `signature` to `3.0.0-pre` by baloo · Pull Request #505 · RustCrypto/RSA

baloo · 2025-04-23T21:46:48Z

No description provided.

tarcieri · 2025-04-23T23:06:09Z

Ugh, that’s really annoying if the blanket impl leads to an inference failure.

Regarding carrying the digest, perhaps something like https://docs.rs/ecdsa/latest/ecdsa/struct.SignatureWithOid.html ?

tarcieri · 2025-04-24T04:22:10Z

I opened RustCrypto/traits#1831 to discuss the inference regression. We might want to consider backing out this change.

baloo · 2025-04-24T04:23:28Z

I'm not sure I get what you're trying to suggest with SignatureWithOid.

I think this overall is a side effect of having to provide the Digest to the blanket Signer, which you can't provide unless you specify that through the resulting type. (Because there could be more than one DigestSigner implemented).

I otherwise think that specifying the digest attached to a signature makes sense (and that we should actually embrace that change, whether or not we fix the inference for it).

tarcieri · 2025-04-24T04:36:22Z

One thing that would be weird about attaching a digest type to the signature type is algorithm information isn't available in the serialized signature, so you'll be able to parse signatures generated by other digest algorithms successfully

baloo · 2025-04-24T04:48:38Z

Yeah but that should be inferred from the VerifierDigest call that should ensue (otherwise the digest can be whatever)

~~Note: Neither the ecdsa::signature nor ecdsa::der::Signature have it either~~ they don’t have digest in the first place

baloo · 2025-04-24T04:52:33Z

Wait, we do have the digest in the SigningKey, there should not be an issue with selecting the DigestSigner. I’ll have another look tomorrow.

baloo · 2025-04-24T17:23:43Z

#505 (comment)
That was actually a red herring, I didn't have PrehashSignature for Signature in the first place, so I could not use the blanket. The only way to implement PrehashSignature would here be to have signature carry the associated digest (which I did).
The type inference works just fine after that.

We get away with not having the Digest in ecdsa::Signature because the associated Digest is used instead.

tarcieri · 2025-04-24T23:27:43Z

-#[derive(Debug, Clone, PartialEq, Eq)]
-pub struct Signature {
+#[derive(Eq)]
+pub struct Signature<D> {


This still seems a little weird to me because there isn't a strong binding or relationship between the signature as a cryptographic object and the digest algorithm that was used to compute it.
This means that the type does not actually maintain an invariant e.g. "this is a signature that was known to be computed by using digest D over the input message". It could've been computed with any digest algorithm.
I guess there's a type safety argument to it in that the type identifies what digest you're supposed to use, but as cryptographic objects they're not really parameterized/distinguished by the digest, it's just something that happens earlier in the computation of the signature.

@baloo WDYT?

I don’t know what I think ^^.
I know that I don’t really have much of a choice.
What I’m arguing it that it makes the digest explicit when accepting/parsing a signature: “I know this is going to be verified with this public key with sha384”
I know the serialization does not necessarily carry this information, although it would be carried via the OID on the object (x509 or cms) or via a specification or however the developer may which. Whichever that might be the digest will need to be provided for the VerifyingKey.
all in all this is a little bit inconvenient, but not all that much and it just makes the digest choice explicit.

I guess the only reason it exists is for the PrehashSignature impl.
I find it a little troubling it otherwise doesn't actually do anything, but I guess we need to merge this to make any progress.

tarcieri · 2025-04-29T20:56:32Z

-#[cfg(feature = "os_rng")]
-impl<D> Signer<Signature> for SigningKey<D>
-where
- D: Digest + FixedOutputReset,
-{
- fn try_sign(&self, msg: &[u8]) -> signature::Result<Signature> {
- self.try_sign_with_rng(&mut OsRng, msg)
- }
-}


I guess the alternative would be to preserve these Signer impls and not impl PrehashSignature for Signature since it's not actually known at the type level

Iirc I tried that, but I came in conflict with the blanket implementation.
can’t try it right this moment, will try that in an hour or so.

If you don't impl PrehashSignature the blanket impl shouldn't matter

yeah looks like it works, but that still mess up the type inference and you need to provide the type of the signature you expect. You don't need to provide the digest thought.
#510

baloo · 2025-05-02T22:43:34Z

closed in favor of #513

baloo · 2025-04-23T21:46:48Z

No description provided.

tarcieri · 2025-04-23T23:06:09Z

Ugh, that’s really annoying if the blanket impl leads to an inference failure.

Regarding carrying the digest, perhaps something like https://docs.rs/ecdsa/latest/ecdsa/struct.SignatureWithOid.html ?

tarcieri · 2025-04-24T04:22:10Z

I opened RustCrypto/traits#1831 to discuss the inference regression. We might want to consider backing out this change.

baloo · 2025-04-24T04:23:28Z

I'm not sure I get what you're trying to suggest with SignatureWithOid.

I think this overall is a side effect of having to provide the Digest to the blanket Signer, which you can't provide unless you specify that through the resulting type. (Because there could be more than one DigestSigner implemented).

I otherwise think that specifying the digest attached to a signature makes sense (and that we should actually embrace that change, whether or not we fix the inference for it).

tarcieri · 2025-04-24T04:36:22Z

One thing that would be weird about attaching a digest type to the signature type is algorithm information isn't available in the serialized signature, so you'll be able to parse signatures generated by other digest algorithms successfully

baloo · 2025-04-24T04:48:38Z

Yeah but that should be inferred from the VerifierDigest call that should ensue (otherwise the digest can be whatever)

~~Note: Neither the ecdsa::signature nor ecdsa::der::Signature have it either~~ they don’t have digest in the first place

baloo · 2025-04-24T04:52:33Z

Wait, we do have the digest in the SigningKey, there should not be an issue with selecting the DigestSigner. I’ll have another look tomorrow.

baloo · 2025-04-24T17:23:43Z

#505 (comment)
That was actually a red herring, I didn't have PrehashSignature for Signature in the first place, so I could not use the blanket. The only way to implement PrehashSignature would here be to have signature carry the associated digest (which I did).
The type inference works just fine after that.

We get away with not having the Digest in ecdsa::Signature because the associated Digest is used instead.

tarcieri · 2025-04-24T23:27:43Z

-#[derive(Debug, Clone, PartialEq, Eq)]
-pub struct Signature {
+#[derive(Eq)]
+pub struct Signature<D> {


This still seems a little weird to me because there isn't a strong binding or relationship between the signature as a cryptographic object and the digest algorithm that was used to compute it.
This means that the type does not actually maintain an invariant e.g. "this is a signature that was known to be computed by using digest D over the input message". It could've been computed with any digest algorithm.
I guess there's a type safety argument to it in that the type identifies what digest you're supposed to use, but as cryptographic objects they're not really parameterized/distinguished by the digest, it's just something that happens earlier in the computation of the signature.

@baloo WDYT?

I don’t know what I think ^^.
I know that I don’t really have much of a choice.
What I’m arguing it that it makes the digest explicit when accepting/parsing a signature: “I know this is going to be verified with this public key with sha384”
I know the serialization does not necessarily carry this information, although it would be carried via the OID on the object (x509 or cms) or via a specification or however the developer may which. Whichever that might be the digest will need to be provided for the VerifyingKey.
all in all this is a little bit inconvenient, but not all that much and it just makes the digest choice explicit.

I guess the only reason it exists is for the PrehashSignature impl.
I find it a little troubling it otherwise doesn't actually do anything, but I guess we need to merge this to make any progress.

tarcieri · 2025-04-29T20:56:32Z

-#[cfg(feature = "os_rng")]
-impl<D> Signer<Signature> for SigningKey<D>
-where
- D: Digest + FixedOutputReset,
-{
- fn try_sign(&self, msg: &[u8]) -> signature::Result<Signature> {
- self.try_sign_with_rng(&mut OsRng, msg)
- }
-}


I guess the alternative would be to preserve these Signer impls and not impl PrehashSignature for Signature since it's not actually known at the type level

Iirc I tried that, but I came in conflict with the blanket implementation.
can’t try it right this moment, will try that in an hour or so.

If you don't impl PrehashSignature the blanket impl shouldn't matter

yeah looks like it works, but that still mess up the type inference and you need to provide the type of the signature you expect. You don't need to provide the digest thought.
#510

baloo · 2025-05-02T22:43:34Z

closed in favor of #513

baloo · 2025-04-23T21:46:48Z

No description provided.

tarcieri · 2025-04-23T23:06:09Z

Ugh, that’s really annoying if the blanket impl leads to an inference failure.

Regarding carrying the digest, perhaps something like https://docs.rs/ecdsa/latest/ecdsa/struct.SignatureWithOid.html ?

tarcieri · 2025-04-24T04:22:10Z

I opened RustCrypto/traits#1831 to discuss the inference regression. We might want to consider backing out this change.

baloo · 2025-04-24T04:23:28Z

I'm not sure I get what you're trying to suggest with SignatureWithOid.

I think this overall is a side effect of having to provide the Digest to the blanket Signer, which you can't provide unless you specify that through the resulting type. (Because there could be more than one DigestSigner implemented).

I otherwise think that specifying the digest attached to a signature makes sense (and that we should actually embrace that change, whether or not we fix the inference for it).

tarcieri · 2025-04-24T04:36:22Z

One thing that would be weird about attaching a digest type to the signature type is algorithm information isn't available in the serialized signature, so you'll be able to parse signatures generated by other digest algorithms successfully

baloo · 2025-04-24T04:48:38Z

Yeah but that should be inferred from the VerifierDigest call that should ensue (otherwise the digest can be whatever)

~~Note: Neither the ecdsa::signature nor ecdsa::der::Signature have it either~~ they don’t have digest in the first place

baloo · 2025-04-24T04:52:33Z

Wait, we do have the digest in the SigningKey, there should not be an issue with selecting the DigestSigner. I’ll have another look tomorrow.

baloo · 2025-04-24T17:23:43Z

#505 (comment)
That was actually a red herring, I didn't have PrehashSignature for Signature in the first place, so I could not use the blanket. The only way to implement PrehashSignature would here be to have signature carry the associated digest (which I did).
The type inference works just fine after that.

We get away with not having the Digest in ecdsa::Signature because the associated Digest is used instead.

tarcieri · 2025-04-24T23:27:43Z

-#[derive(Debug, Clone, PartialEq, Eq)]
-pub struct Signature {
+#[derive(Eq)]
+pub struct Signature<D> {


This still seems a little weird to me because there isn't a strong binding or relationship between the signature as a cryptographic object and the digest algorithm that was used to compute it.
This means that the type does not actually maintain an invariant e.g. "this is a signature that was known to be computed by using digest D over the input message". It could've been computed with any digest algorithm.
I guess there's a type safety argument to it in that the type identifies what digest you're supposed to use, but as cryptographic objects they're not really parameterized/distinguished by the digest, it's just something that happens earlier in the computation of the signature.

@baloo WDYT?

I don’t know what I think ^^.
I know that I don’t really have much of a choice.
What I’m arguing it that it makes the digest explicit when accepting/parsing a signature: “I know this is going to be verified with this public key with sha384”
I know the serialization does not necessarily carry this information, although it would be carried via the OID on the object (x509 or cms) or via a specification or however the developer may which. Whichever that might be the digest will need to be provided for the VerifyingKey.
all in all this is a little bit inconvenient, but not all that much and it just makes the digest choice explicit.

I guess the only reason it exists is for the PrehashSignature impl.
I find it a little troubling it otherwise doesn't actually do anything, but I guess we need to merge this to make any progress.

tarcieri · 2025-04-29T20:56:32Z

-#[cfg(feature = "os_rng")]
-impl<D> Signer<Signature> for SigningKey<D>
-where
- D: Digest + FixedOutputReset,
-{
- fn try_sign(&self, msg: &[u8]) -> signature::Result<Signature> {
- self.try_sign_with_rng(&mut OsRng, msg)
- }
-}


I guess the alternative would be to preserve these Signer impls and not impl PrehashSignature for Signature since it's not actually known at the type level

Iirc I tried that, but I came in conflict with the blanket implementation.
can’t try it right this moment, will try that in an hour or so.

If you don't impl PrehashSignature the blanket impl shouldn't matter

yeah looks like it works, but that still mess up the type inference and you need to provide the type of the signature you expect. You don't need to provide the digest thought.
#510

baloo · 2025-05-02T22:43:34Z

closed in favor of #513

baloo · 2025-04-23T21:46:48Z

No description provided.

tarcieri · 2025-04-23T23:06:09Z

Ugh, that’s really annoying if the blanket impl leads to an inference failure.

Regarding carrying the digest, perhaps something like https://docs.rs/ecdsa/latest/ecdsa/struct.SignatureWithOid.html ?

tarcieri · 2025-04-24T04:22:10Z

I opened RustCrypto/traits#1831 to discuss the inference regression. We might want to consider backing out this change.

baloo · 2025-04-24T04:23:28Z

I'm not sure I get what you're trying to suggest with SignatureWithOid.

I think this overall is a side effect of having to provide the Digest to the blanket Signer, which you can't provide unless you specify that through the resulting type. (Because there could be more than one DigestSigner implemented).

I otherwise think that specifying the digest attached to a signature makes sense (and that we should actually embrace that change, whether or not we fix the inference for it).

tarcieri · 2025-04-24T04:36:22Z

One thing that would be weird about attaching a digest type to the signature type is algorithm information isn't available in the serialized signature, so you'll be able to parse signatures generated by other digest algorithms successfully

baloo · 2025-04-24T04:48:38Z

Yeah but that should be inferred from the VerifierDigest call that should ensue (otherwise the digest can be whatever)

~~Note: Neither the ecdsa::signature nor ecdsa::der::Signature have it either~~ they don’t have digest in the first place

baloo · 2025-04-24T04:52:33Z

Wait, we do have the digest in the SigningKey, there should not be an issue with selecting the DigestSigner. I’ll have another look tomorrow.

baloo · 2025-04-24T17:23:43Z

#505 (comment)
That was actually a red herring, I didn't have PrehashSignature for Signature in the first place, so I could not use the blanket. The only way to implement PrehashSignature would here be to have signature carry the associated digest (which I did).
The type inference works just fine after that.

We get away with not having the Digest in ecdsa::Signature because the associated Digest is used instead.

tarcieri · 2025-04-24T23:27:43Z

-#[derive(Debug, Clone, PartialEq, Eq)]
-pub struct Signature {
+#[derive(Eq)]
+pub struct Signature<D> {


This still seems a little weird to me because there isn't a strong binding or relationship between the signature as a cryptographic object and the digest algorithm that was used to compute it.
This means that the type does not actually maintain an invariant e.g. "this is a signature that was known to be computed by using digest D over the input message". It could've been computed with any digest algorithm.
I guess there's a type safety argument to it in that the type identifies what digest you're supposed to use, but as cryptographic objects they're not really parameterized/distinguished by the digest, it's just something that happens earlier in the computation of the signature.

@baloo WDYT?

I don’t know what I think ^^.
I know that I don’t really have much of a choice.
What I’m arguing it that it makes the digest explicit when accepting/parsing a signature: “I know this is going to be verified with this public key with sha384”
I know the serialization does not necessarily carry this information, although it would be carried via the OID on the object (x509 or cms) or via a specification or however the developer may which. Whichever that might be the digest will need to be provided for the VerifyingKey.
all in all this is a little bit inconvenient, but not all that much and it just makes the digest choice explicit.

I guess the only reason it exists is for the PrehashSignature impl.
I find it a little troubling it otherwise doesn't actually do anything, but I guess we need to merge this to make any progress.

tarcieri · 2025-04-29T20:56:32Z

-#[cfg(feature = "os_rng")]
-impl<D> Signer<Signature> for SigningKey<D>
-where
- D: Digest + FixedOutputReset,
-{
- fn try_sign(&self, msg: &[u8]) -> signature::Result<Signature> {
- self.try_sign_with_rng(&mut OsRng, msg)
- }
-}


I guess the alternative would be to preserve these Signer impls and not impl PrehashSignature for Signature since it's not actually known at the type level

Iirc I tried that, but I came in conflict with the blanket implementation.
can’t try it right this moment, will try that in an hour or so.

If you don't impl PrehashSignature the blanket impl shouldn't matter

yeah looks like it works, but that still mess up the type inference and you need to provide the type of the signature you expect. You don't need to provide the digest thought.
#510

baloo · 2025-05-02T22:43:34Z

closed in favor of #513

baloo · 2025-04-23T21:46:48Z

No description provided.

tarcieri · 2025-04-23T23:06:09Z

Ugh, that’s really annoying if the blanket impl leads to an inference failure.

Regarding carrying the digest, perhaps something like https://docs.rs/ecdsa/latest/ecdsa/struct.SignatureWithOid.html ?

tarcieri · 2025-04-24T04:22:10Z

I opened RustCrypto/traits#1831 to discuss the inference regression. We might want to consider backing out this change.

baloo · 2025-04-24T04:23:28Z

I'm not sure I get what you're trying to suggest with SignatureWithOid.

I think this overall is a side effect of having to provide the Digest to the blanket Signer, which you can't provide unless you specify that through the resulting type. (Because there could be more than one DigestSigner implemented).

I otherwise think that specifying the digest attached to a signature makes sense (and that we should actually embrace that change, whether or not we fix the inference for it).

tarcieri · 2025-04-24T04:36:22Z

One thing that would be weird about attaching a digest type to the signature type is algorithm information isn't available in the serialized signature, so you'll be able to parse signatures generated by other digest algorithms successfully

baloo · 2025-04-24T04:48:38Z

Yeah but that should be inferred from the VerifierDigest call that should ensue (otherwise the digest can be whatever)

~~Note: Neither the ecdsa::signature nor ecdsa::der::Signature have it either~~ they don’t have digest in the first place

baloo · 2025-04-24T04:52:33Z

Wait, we do have the digest in the SigningKey, there should not be an issue with selecting the DigestSigner. I’ll have another look tomorrow.

baloo · 2025-04-24T17:23:43Z

#505 (comment)
That was actually a red herring, I didn't have PrehashSignature for Signature in the first place, so I could not use the blanket. The only way to implement PrehashSignature would here be to have signature carry the associated digest (which I did).
The type inference works just fine after that.

We get away with not having the Digest in ecdsa::Signature because the associated Digest is used instead.

tarcieri · 2025-04-24T23:27:43Z

-#[derive(Debug, Clone, PartialEq, Eq)]
-pub struct Signature {
+#[derive(Eq)]
+pub struct Signature<D> {


This still seems a little weird to me because there isn't a strong binding or relationship between the signature as a cryptographic object and the digest algorithm that was used to compute it.
This means that the type does not actually maintain an invariant e.g. "this is a signature that was known to be computed by using digest D over the input message". It could've been computed with any digest algorithm.
I guess there's a type safety argument to it in that the type identifies what digest you're supposed to use, but as cryptographic objects they're not really parameterized/distinguished by the digest, it's just something that happens earlier in the computation of the signature.

@baloo WDYT?

I don’t know what I think ^^.
I know that I don’t really have much of a choice.
What I’m arguing it that it makes the digest explicit when accepting/parsing a signature: “I know this is going to be verified with this public key with sha384”
I know the serialization does not necessarily carry this information, although it would be carried via the OID on the object (x509 or cms) or via a specification or however the developer may which. Whichever that might be the digest will need to be provided for the VerifyingKey.
all in all this is a little bit inconvenient, but not all that much and it just makes the digest choice explicit.

I guess the only reason it exists is for the PrehashSignature impl.
I find it a little troubling it otherwise doesn't actually do anything, but I guess we need to merge this to make any progress.

tarcieri · 2025-04-29T20:56:32Z

-#[cfg(feature = "os_rng")]
-impl<D> Signer<Signature> for SigningKey<D>
-where
- D: Digest + FixedOutputReset,
-{
- fn try_sign(&self, msg: &[u8]) -> signature::Result<Signature> {
- self.try_sign_with_rng(&mut OsRng, msg)
- }
-}


I guess the alternative would be to preserve these Signer impls and not impl PrehashSignature for Signature since it's not actually known at the type level

Iirc I tried that, but I came in conflict with the blanket implementation.
can’t try it right this moment, will try that in an hour or so.

If you don't impl PrehashSignature the blanket impl shouldn't matter

yeah looks like it works, but that still mess up the type inference and you need to provide the type of the signature you expect. You don't need to provide the digest thought.
#510

baloo · 2025-05-02T22:43:34Z

closed in favor of #513

baloo · 2025-04-23T21:46:48Z

No description provided.

tarcieri · 2025-04-23T23:06:09Z

Ugh, that’s really annoying if the blanket impl leads to an inference failure.

Regarding carrying the digest, perhaps something like https://docs.rs/ecdsa/latest/ecdsa/struct.SignatureWithOid.html ?

tarcieri · 2025-04-24T04:22:10Z

I opened RustCrypto/traits#1831 to discuss the inference regression. We might want to consider backing out this change.

baloo · 2025-04-24T04:23:28Z

I'm not sure I get what you're trying to suggest with SignatureWithOid.

I think this overall is a side effect of having to provide the Digest to the blanket Signer, which you can't provide unless you specify that through the resulting type. (Because there could be more than one DigestSigner implemented).

I otherwise think that specifying the digest attached to a signature makes sense (and that we should actually embrace that change, whether or not we fix the inference for it).

tarcieri · 2025-04-24T04:36:22Z

One thing that would be weird about attaching a digest type to the signature type is algorithm information isn't available in the serialized signature, so you'll be able to parse signatures generated by other digest algorithms successfully

baloo · 2025-04-24T04:48:38Z

Yeah but that should be inferred from the VerifierDigest call that should ensue (otherwise the digest can be whatever)

~~Note: Neither the ecdsa::signature nor ecdsa::der::Signature have it either~~ they don’t have digest in the first place

baloo · 2025-04-24T04:52:33Z

Wait, we do have the digest in the SigningKey, there should not be an issue with selecting the DigestSigner. I’ll have another look tomorrow.

baloo · 2025-04-24T17:23:43Z

#505 (comment)
That was actually a red herring, I didn't have PrehashSignature for Signature in the first place, so I could not use the blanket. The only way to implement PrehashSignature would here be to have signature carry the associated digest (which I did).
The type inference works just fine after that.

We get away with not having the Digest in ecdsa::Signature because the associated Digest is used instead.

tarcieri · 2025-04-24T23:27:43Z

-#[derive(Debug, Clone, PartialEq, Eq)]
-pub struct Signature {
+#[derive(Eq)]
+pub struct Signature<D> {


This still seems a little weird to me because there isn't a strong binding or relationship between the signature as a cryptographic object and the digest algorithm that was used to compute it.
This means that the type does not actually maintain an invariant e.g. "this is a signature that was known to be computed by using digest D over the input message". It could've been computed with any digest algorithm.
I guess there's a type safety argument to it in that the type identifies what digest you're supposed to use, but as cryptographic objects they're not really parameterized/distinguished by the digest, it's just something that happens earlier in the computation of the signature.

@baloo WDYT?

I don’t know what I think ^^.
I know that I don’t really have much of a choice.
What I’m arguing it that it makes the digest explicit when accepting/parsing a signature: “I know this is going to be verified with this public key with sha384”
I know the serialization does not necessarily carry this information, although it would be carried via the OID on the object (x509 or cms) or via a specification or however the developer may which. Whichever that might be the digest will need to be provided for the VerifyingKey.
all in all this is a little bit inconvenient, but not all that much and it just makes the digest choice explicit.

I guess the only reason it exists is for the PrehashSignature impl.
I find it a little troubling it otherwise doesn't actually do anything, but I guess we need to merge this to make any progress.

tarcieri · 2025-04-29T20:56:32Z

-#[cfg(feature = "os_rng")]
-impl<D> Signer<Signature> for SigningKey<D>
-where
- D: Digest + FixedOutputReset,
-{
- fn try_sign(&self, msg: &[u8]) -> signature::Result<Signature> {
- self.try_sign_with_rng(&mut OsRng, msg)
- }
-}


I guess the alternative would be to preserve these Signer impls and not impl PrehashSignature for Signature since it's not actually known at the type level

Iirc I tried that, but I came in conflict with the blanket implementation.
can’t try it right this moment, will try that in an hour or so.

If you don't impl PrehashSignature the blanket impl shouldn't matter

yeah looks like it works, but that still mess up the type inference and you need to provide the type of the signature you expect. You don't need to provide the digest thought.
#510

baloo · 2025-05-02T22:43:34Z

closed in favor of #513

baloo · 2025-04-23T21:46:48Z

No description provided.

tarcieri · 2025-04-23T23:06:09Z

Ugh, that’s really annoying if the blanket impl leads to an inference failure.

Regarding carrying the digest, perhaps something like https://docs.rs/ecdsa/latest/ecdsa/struct.SignatureWithOid.html ?

tarcieri · 2025-04-24T04:22:10Z

I opened RustCrypto/traits#1831 to discuss the inference regression. We might want to consider backing out this change.

baloo · 2025-04-24T04:23:28Z

I'm not sure I get what you're trying to suggest with SignatureWithOid.

I think this overall is a side effect of having to provide the Digest to the blanket Signer, which you can't provide unless you specify that through the resulting type. (Because there could be more than one DigestSigner implemented).

I otherwise think that specifying the digest attached to a signature makes sense (and that we should actually embrace that change, whether or not we fix the inference for it).

tarcieri · 2025-04-24T04:36:22Z

One thing that would be weird about attaching a digest type to the signature type is algorithm information isn't available in the serialized signature, so you'll be able to parse signatures generated by other digest algorithms successfully

baloo · 2025-04-24T04:48:38Z

Yeah but that should be inferred from the VerifierDigest call that should ensue (otherwise the digest can be whatever)

~~Note: Neither the ecdsa::signature nor ecdsa::der::Signature have it either~~ they don’t have digest in the first place

baloo · 2025-04-24T04:52:33Z

Wait, we do have the digest in the SigningKey, there should not be an issue with selecting the DigestSigner. I’ll have another look tomorrow.

baloo · 2025-04-24T17:23:43Z

#505 (comment)
That was actually a red herring, I didn't have PrehashSignature for Signature in the first place, so I could not use the blanket. The only way to implement PrehashSignature would here be to have signature carry the associated digest (which I did).
The type inference works just fine after that.

We get away with not having the Digest in ecdsa::Signature because the associated Digest is used instead.

tarcieri · 2025-04-24T23:27:43Z

-#[derive(Debug, Clone, PartialEq, Eq)]
-pub struct Signature {
+#[derive(Eq)]
+pub struct Signature<D> {


This still seems a little weird to me because there isn't a strong binding or relationship between the signature as a cryptographic object and the digest algorithm that was used to compute it.
This means that the type does not actually maintain an invariant e.g. "this is a signature that was known to be computed by using digest D over the input message". It could've been computed with any digest algorithm.
I guess there's a type safety argument to it in that the type identifies what digest you're supposed to use, but as cryptographic objects they're not really parameterized/distinguished by the digest, it's just something that happens earlier in the computation of the signature.

@baloo WDYT?

I don’t know what I think ^^.
I know that I don’t really have much of a choice.
What I’m arguing it that it makes the digest explicit when accepting/parsing a signature: “I know this is going to be verified with this public key with sha384”
I know the serialization does not necessarily carry this information, although it would be carried via the OID on the object (x509 or cms) or via a specification or however the developer may which. Whichever that might be the digest will need to be provided for the VerifyingKey.
all in all this is a little bit inconvenient, but not all that much and it just makes the digest choice explicit.

I guess the only reason it exists is for the PrehashSignature impl.
I find it a little troubling it otherwise doesn't actually do anything, but I guess we need to merge this to make any progress.

tarcieri · 2025-04-29T20:56:32Z

-#[cfg(feature = "os_rng")]
-impl<D> Signer<Signature> for SigningKey<D>
-where
- D: Digest + FixedOutputReset,
-{
- fn try_sign(&self, msg: &[u8]) -> signature::Result<Signature> {
- self.try_sign_with_rng(&mut OsRng, msg)
- }
-}


I guess the alternative would be to preserve these Signer impls and not impl PrehashSignature for Signature since it's not actually known at the type level

Iirc I tried that, but I came in conflict with the blanket implementation.
can’t try it right this moment, will try that in an hour or so.

If you don't impl PrehashSignature the blanket impl shouldn't matter

yeah looks like it works, but that still mess up the type inference and you need to provide the type of the signature you expect. You don't need to provide the digest thought.
#510

baloo · 2025-05-02T22:43:34Z

closed in favor of #513

baloo · 2025-04-23T21:46:48Z

No description provided.

tarcieri · 2025-04-23T23:06:09Z

Ugh, that’s really annoying if the blanket impl leads to an inference failure.

Regarding carrying the digest, perhaps something like https://docs.rs/ecdsa/latest/ecdsa/struct.SignatureWithOid.html ?

tarcieri · 2025-04-24T04:22:10Z

I opened RustCrypto/traits#1831 to discuss the inference regression. We might want to consider backing out this change.

baloo · 2025-04-24T04:23:28Z

I'm not sure I get what you're trying to suggest with SignatureWithOid.

I think this overall is a side effect of having to provide the Digest to the blanket Signer, which you can't provide unless you specify that through the resulting type. (Because there could be more than one DigestSigner implemented).

I otherwise think that specifying the digest attached to a signature makes sense (and that we should actually embrace that change, whether or not we fix the inference for it).

tarcieri · 2025-04-24T04:36:22Z

One thing that would be weird about attaching a digest type to the signature type is algorithm information isn't available in the serialized signature, so you'll be able to parse signatures generated by other digest algorithms successfully

baloo · 2025-04-24T04:48:38Z

Yeah but that should be inferred from the VerifierDigest call that should ensue (otherwise the digest can be whatever)

~~Note: Neither the ecdsa::signature nor ecdsa::der::Signature have it either~~ they don’t have digest in the first place

baloo · 2025-04-24T04:52:33Z

Wait, we do have the digest in the SigningKey, there should not be an issue with selecting the DigestSigner. I’ll have another look tomorrow.

baloo · 2025-04-24T17:23:43Z

#505 (comment)
That was actually a red herring, I didn't have PrehashSignature for Signature in the first place, so I could not use the blanket. The only way to implement PrehashSignature would here be to have signature carry the associated digest (which I did).
The type inference works just fine after that.

We get away with not having the Digest in ecdsa::Signature because the associated Digest is used instead.

tarcieri · 2025-04-24T23:27:43Z

-#[derive(Debug, Clone, PartialEq, Eq)]
-pub struct Signature {
+#[derive(Eq)]
+pub struct Signature<D> {


This still seems a little weird to me because there isn't a strong binding or relationship between the signature as a cryptographic object and the digest algorithm that was used to compute it.
This means that the type does not actually maintain an invariant e.g. "this is a signature that was known to be computed by using digest D over the input message". It could've been computed with any digest algorithm.
I guess there's a type safety argument to it in that the type identifies what digest you're supposed to use, but as cryptographic objects they're not really parameterized/distinguished by the digest, it's just something that happens earlier in the computation of the signature.

@baloo WDYT?

I don’t know what I think ^^.
I know that I don’t really have much of a choice.
What I’m arguing it that it makes the digest explicit when accepting/parsing a signature: “I know this is going to be verified with this public key with sha384”
I know the serialization does not necessarily carry this information, although it would be carried via the OID on the object (x509 or cms) or via a specification or however the developer may which. Whichever that might be the digest will need to be provided for the VerifyingKey.
all in all this is a little bit inconvenient, but not all that much and it just makes the digest choice explicit.

I guess the only reason it exists is for the PrehashSignature impl.
I find it a little troubling it otherwise doesn't actually do anything, but I guess we need to merge this to make any progress.

tarcieri · 2025-04-29T20:56:32Z

-#[cfg(feature = "os_rng")]
-impl<D> Signer<Signature> for SigningKey<D>
-where
- D: Digest + FixedOutputReset,
-{
- fn try_sign(&self, msg: &[u8]) -> signature::Result<Signature> {
- self.try_sign_with_rng(&mut OsRng, msg)
- }
-}


I guess the alternative would be to preserve these Signer impls and not impl PrehashSignature for Signature since it's not actually known at the type level

Iirc I tried that, but I came in conflict with the blanket implementation.
can’t try it right this moment, will try that in an hour or so.

If you don't impl PrehashSignature the blanket impl shouldn't matter

yeah looks like it works, but that still mess up the type inference and you need to provide the type of the signature you expect. You don't need to provide the digest thought.
#510

baloo · 2025-05-02T22:43:34Z

closed in favor of #513

baloo marked this pull request as draft April 23, 2025 21:46

baloo force-pushed the baloo/signature/3 branch 2 times, most recently from eaaea51 to e81c85aCompare April 23, 2025 22:31

baloo marked this pull request as ready for review April 23, 2025 22:32

chore(deps): bump signature to 3.0.0-pre
22a4bd9

baloo force-pushed the baloo/signature/3 branch from e81c85a to 22a4bd9Compare April 23, 2025 22:34

baloo mentioned this pull request Apr 24, 2025
Bump to signature 3 RustCrypto/formats#1784
Merged

tarcieri mentioned this pull request Apr 24, 2025
signature v3: type inference regression RustCrypto/traits#1831
Closed

tarcieri reviewed Apr 24, 2025
View reviewed changes

tarcieri approved these changes Apr 29, 2025
View reviewed changes

tarcieri reviewed Apr 29, 2025
View reviewed changes

baloo mentioned this pull request Apr 30, 2025
Bump to signature 3 #510
Closed

baloo closed this May 2, 2025

baloo deleted the baloo/signature/3 branch May 2, 2025 22:43

tarcieri mentioned this pull request Aug 7, 2025
Generic digest for rsa::pkcs1v15::Signature? #364
Open

baloo marked this pull request as draft April 23, 2025 21:46

baloo force-pushed the baloo/signature/3 branch 2 times, most recently from eaaea51 to e81c85aCompare April 23, 2025 22:31

baloo marked this pull request as ready for review April 23, 2025 22:32

chore(deps): bump signature to 3.0.0-pre
22a4bd9

baloo force-pushed the baloo/signature/3 branch from e81c85a to 22a4bd9Compare April 23, 2025 22:34

baloo mentioned this pull request Apr 24, 2025
Bump to signature 3 RustCrypto/formats#1784
Merged

tarcieri mentioned this pull request Apr 24, 2025
signature v3: type inference regression RustCrypto/traits#1831
Closed

tarcieri reviewed Apr 24, 2025
View reviewed changes

tarcieri approved these changes Apr 29, 2025
View reviewed changes

tarcieri reviewed Apr 29, 2025
View reviewed changes

baloo mentioned this pull request Apr 30, 2025
Bump to signature 3 #510
Closed

baloo closed this May 2, 2025

baloo deleted the baloo/signature/3 branch May 2, 2025 22:43

tarcieri mentioned this pull request Aug 7, 2025
Generic digest for rsa::pkcs1v15::Signature? #364
Open

baloo marked this pull request as draft April 23, 2025 21:46

baloo force-pushed the baloo/signature/3 branch 2 times, most recently from eaaea51 to e81c85aCompare April 23, 2025 22:31

baloo marked this pull request as ready for review April 23, 2025 22:32

chore(deps): bump signature to 3.0.0-pre
22a4bd9

baloo force-pushed the baloo/signature/3 branch from e81c85a to 22a4bd9Compare April 23, 2025 22:34

baloo mentioned this pull request Apr 24, 2025
Bump to signature 3 RustCrypto/formats#1784
Merged

tarcieri mentioned this pull request Apr 24, 2025
signature v3: type inference regression RustCrypto/traits#1831
Closed

tarcieri reviewed Apr 24, 2025
View reviewed changes

tarcieri approved these changes Apr 29, 2025
View reviewed changes

tarcieri reviewed Apr 29, 2025
View reviewed changes

baloo mentioned this pull request Apr 30, 2025
Bump to signature 3 #510
Closed

baloo closed this May 2, 2025

baloo deleted the baloo/signature/3 branch May 2, 2025 22:43

tarcieri mentioned this pull request Aug 7, 2025
Generic digest for rsa::pkcs1v15::Signature? #364
Open

baloo marked this pull request as draft April 23, 2025 21:46

baloo force-pushed the baloo/signature/3 branch 2 times, most recently from eaaea51 to e81c85aCompare April 23, 2025 22:31

baloo marked this pull request as ready for review April 23, 2025 22:32

chore(deps): bump signature to 3.0.0-pre
22a4bd9

baloo force-pushed the baloo/signature/3 branch from e81c85a to 22a4bd9Compare April 23, 2025 22:34

baloo mentioned this pull request Apr 24, 2025
Bump to signature 3 RustCrypto/formats#1784
Merged

tarcieri mentioned this pull request Apr 24, 2025
signature v3: type inference regression RustCrypto/traits#1831
Closed

tarcieri reviewed Apr 24, 2025
View reviewed changes

tarcieri approved these changes Apr 29, 2025
View reviewed changes

tarcieri reviewed Apr 29, 2025
View reviewed changes

baloo mentioned this pull request Apr 30, 2025
Bump to signature 3 #510
Closed

baloo closed this May 2, 2025

baloo deleted the baloo/signature/3 branch May 2, 2025 22:43

tarcieri mentioned this pull request Aug 7, 2025
Generic digest for rsa::pkcs1v15::Signature? #364
Open

baloo marked this pull request as draft April 23, 2025 21:46

baloo force-pushed the baloo/signature/3 branch 2 times, most recently from eaaea51 to e81c85aCompare April 23, 2025 22:31

baloo marked this pull request as ready for review April 23, 2025 22:32

chore(deps): bump signature to 3.0.0-pre
22a4bd9

baloo force-pushed the baloo/signature/3 branch from e81c85a to 22a4bd9Compare April 23, 2025 22:34

baloo mentioned this pull request Apr 24, 2025
Bump to signature 3 RustCrypto/formats#1784
Merged

tarcieri mentioned this pull request Apr 24, 2025
signature v3: type inference regression RustCrypto/traits#1831
Closed

tarcieri reviewed Apr 24, 2025
View reviewed changes

tarcieri approved these changes Apr 29, 2025
View reviewed changes

tarcieri reviewed Apr 29, 2025
View reviewed changes

baloo mentioned this pull request Apr 30, 2025
Bump to signature 3 #510
Closed

baloo closed this May 2, 2025

baloo deleted the baloo/signature/3 branch May 2, 2025 22:43

tarcieri mentioned this pull request Aug 7, 2025
Generic digest for rsa::pkcs1v15::Signature? #364
Open

baloo marked this pull request as draft April 23, 2025 21:46

baloo force-pushed the baloo/signature/3 branch 2 times, most recently from eaaea51 to e81c85aCompare April 23, 2025 22:31

baloo marked this pull request as ready for review April 23, 2025 22:32

chore(deps): bump signature to 3.0.0-pre
22a4bd9

baloo force-pushed the baloo/signature/3 branch from e81c85a to 22a4bd9Compare April 23, 2025 22:34

baloo mentioned this pull request Apr 24, 2025
Bump to signature 3 RustCrypto/formats#1784
Merged

tarcieri mentioned this pull request Apr 24, 2025
signature v3: type inference regression RustCrypto/traits#1831
Closed

tarcieri reviewed Apr 24, 2025
View reviewed changes

tarcieri approved these changes Apr 29, 2025
View reviewed changes

tarcieri reviewed Apr 29, 2025
View reviewed changes

baloo mentioned this pull request Apr 30, 2025
Bump to signature 3 #510
Closed

baloo closed this May 2, 2025

baloo deleted the baloo/signature/3 branch May 2, 2025 22:43

tarcieri mentioned this pull request Aug 7, 2025
Generic digest for rsa::pkcs1v15::Signature? #364
Open

baloo marked this pull request as draft April 23, 2025 21:46

baloo force-pushed the baloo/signature/3 branch 2 times, most recently from eaaea51 to e81c85aCompare April 23, 2025 22:31

baloo marked this pull request as ready for review April 23, 2025 22:32

chore(deps): bump signature to 3.0.0-pre
22a4bd9

baloo force-pushed the baloo/signature/3 branch from e81c85a to 22a4bd9Compare April 23, 2025 22:34

baloo mentioned this pull request Apr 24, 2025
Bump to signature 3 RustCrypto/formats#1784
Merged

tarcieri mentioned this pull request Apr 24, 2025
signature v3: type inference regression RustCrypto/traits#1831
Closed

tarcieri reviewed Apr 24, 2025
View reviewed changes

tarcieri approved these changes Apr 29, 2025
View reviewed changes

tarcieri reviewed Apr 29, 2025
View reviewed changes

baloo mentioned this pull request Apr 30, 2025
Bump to signature 3 #510
Closed

baloo closed this May 2, 2025

baloo deleted the baloo/signature/3 branch May 2, 2025 22:43

tarcieri mentioned this pull request Aug 7, 2025
Generic digest for rsa::pkcs1v15::Signature? #364
Open

baloo marked this pull request as draft April 23, 2025 21:46

baloo force-pushed the baloo/signature/3 branch 2 times, most recently from eaaea51 to e81c85aCompare April 23, 2025 22:31

baloo marked this pull request as ready for review April 23, 2025 22:32

chore(deps): bump signature to 3.0.0-pre
22a4bd9

baloo force-pushed the baloo/signature/3 branch from e81c85a to 22a4bd9Compare April 23, 2025 22:34

baloo mentioned this pull request Apr 24, 2025
Bump to signature 3 RustCrypto/formats#1784
Merged

tarcieri mentioned this pull request Apr 24, 2025
signature v3: type inference regression RustCrypto/traits#1831
Closed

tarcieri reviewed Apr 24, 2025
View reviewed changes

tarcieri approved these changes Apr 29, 2025
View reviewed changes

tarcieri reviewed Apr 29, 2025
View reviewed changes

baloo mentioned this pull request Apr 30, 2025
Bump to signature 3 #510
Closed

baloo closed this May 2, 2025

baloo deleted the baloo/signature/3 branch May 2, 2025 22:43

tarcieri mentioned this pull request Aug 7, 2025
Generic digest for rsa::pkcs1v15::Signature? #364
Open

Uh oh!

Conversation

baloo commented Apr 23, 2025

Uh oh!

tarcieri commented Apr 23, 2025

Uh oh!

tarcieri commented Apr 24, 2025

Uh oh!

baloo commented Apr 24, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tarcieri commented Apr 24, 2025

Uh oh!

baloo commented Apr 24, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

baloo commented Apr 24, 2025

Uh oh!

baloo commented Apr 24, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

baloo commented May 2, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

baloo commented Apr 23, 2025

Uh oh!

tarcieri commented Apr 23, 2025

Uh oh!

tarcieri commented Apr 24, 2025

Uh oh!

baloo commented Apr 24, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tarcieri commented Apr 24, 2025

Uh oh!

baloo commented Apr 24, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

baloo commented Apr 24, 2025

Uh oh!

baloo commented Apr 24, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

baloo commented Apr 24, 2025•
edited
Loading

baloo commented Apr 24, 2025•
edited
Loading

baloo commented Apr 24, 2025•
edited
Loading

baloo commented Apr 24, 2025•
edited
Loading

baloo commented Apr 24, 2025•
edited
Loading

baloo commented Apr 24, 2025•
edited
Loading