On 2026-05-27 at 17:40:56, David A. Wheeler wrote: > It's actually worse than that. Several cryptographic signing > algorithms require nonces (long random values); to get the same > signature result, you'd need the same artifact, same private key, > *and* same nonce. > > However, in several algorithms, if you *ever* reuse a nonce for a > differen artifact and a given private key, you reveal the private key. > So if you retain a nonce, generate something but it turns out to be > different, and sign, you've exposed the private key. This footgun will > happen sooner or later if you try to re-sign with the same private key > in a way that reproduces the final signature.
Ed25519 is deterministic and smart ECDSA implementers use deterministic ECDSA as well. Requiring randomness in signatures exposes your private key when you have a bad CSPRNG. > Signatures should *not* be considered part of the item you're > reproducing. Signatures attest something about an artifact; added > signatures of attestation do not change the artifact being attested. Unfortunately, you're at least a decade too late to hold that position when it comes to Git objects. Git includes the signature as part of the object ID and there is no plan to change that. In fact, I agree with that decision since it makes the signature functionally impossible to modify or remove. The current Git testsuite requires objects to hold the same object ID when signed with `gpg --faked-system-time` and if that doesn't happen, then Sequoia will simply not be supported in Git's testsuite[0]. There are other changes for Sequoia to work properly and I don't have any plans to send those upstream until there is a version in Debian unstable that will pass the testsuite. Since I use Sequoia as `gpg`, I would like it to be supported since not having it prevents me from running signing tests, which as a Git developer (and specifically, as the one doing the SHA-1/SHA-256 interoperability work) I would like to run without hassle. [0] While we have moved away from fixed object IDs in the testsuite as much as possible, the code in question tests the SHA-1/SHA-256 object conversion code where we really want to have bit-for-bit identical objects so we know that the conversion code for an algorithm produces the same code as creating a repository natively in that algorithm. Hence, we use the object IDs to verify that the objects are identical in both cases. -- brian m. carlson (they/them) Toronto, Ontario, CA
signature.asc
Description: PGP signature
