As I understand it, Schnorr signatures are the "natural" (and simplest) construction for a digital signature in elliptic curve cryptography. The reason ECDSA exists is simply https://patents.google.com/patent/US4995082 (now expired), which made Schnorr illegal to use, so something worse had to be invented.
Schnorr signatures have a "linearity" property -- if you add together two signatures you get a valid signature of the same text using the sum of the keys.
Sometimes you don't want people to be able to obtain signatures-with-the-sum-of-the-keys, or you don't want to enable bulk key-cracking via the same techniques that allow bulk validation.
Also, confusingly, "EdDSA" signatures (aka ed25519 signatures) are Schnorr signatures:
1. Uses hashing instead of either multiplicative inverse (slow) or a source of randomness (footgun) for the nonce.
2. Hashes the public key into the signature in order to deliberately break linearity. Signatures with different keys will use different hashes, and hashing isn't linear, so adding the signatures no longer yields anything useful. The signature verifier checks this (they can, since they have your public key), so a defective implementation can't skip this step without producing bogus signatures.
somezero 772 days ago [-]
EdDSA signatures are not Schnorr signatures. A Schnorr signature is dlog proof made non interactive with fiat Shamir binded with the message, and that is equivalent/verifiable as an EdDSA signature, up to one time signing per message (as Schnorr is not deterministic)
EdDSA being deterministic, means it’s not Schnorr by definition.
The other difference of EdDSA is having a different keygen process: SHA512 then clamp the first 32 bytes (and this process breaks down all additive key derivation that’s nice to have) clamping is not the problem and you have to clear cofactors for Schnorr over that curve anyway, but it’s the hashing at the beginning that’s different and has nothing to do with cofactor clearing.
The other difference of EdDSA is not having a standardized verifier (keywords are “cofactored” and “cofactorless” verifier) and this breaks down another nice property of Schnorr signatures which is signature aggregation.
Overall the standards for EdDSA -unfortunately- still leave a lot to be desired.
userbinator 774 days ago [-]
The most widely-used (but not widely-known) application of Schnorr signatures may be in Microsoft's product keys. Of course they used a much smaller private key than we'd think is normal today, and as a result, I believe it's been cracked for everything up to ~XP.
wslh 774 days ago [-]
Do you have any source for that? Another alternative to generate livense keys is via Feistel Networks or just random generation.
I was searching for implementations to get a more concrete idea of the algorithm and came across https://github.com/Yawning/secp256k1-voi which appears to be well commented, robust, and oddly entertaining. It’s got Schnorr, and ECDSA for comparison.
There’s also a musig2 one by the same author.
adastra22 773 days ago [-]
> No, this has not been audited. Fuck you, pay me.
Sort of.
Schnorr signatures have a "linearity" property -- if you add together two signatures you get a valid signature of the same text using the sum of the keys.
Sometimes you don't want people to be able to obtain signatures-with-the-sum-of-the-keys, or you don't want to enable bulk key-cracking via the same techniques that allow bulk validation.
Also, confusingly, "EdDSA" signatures (aka ed25519 signatures) are Schnorr signatures:
https://datatracker.ietf.org/doc/html/rfc8032#section-1
... however EdDSA:
1. Uses hashing instead of either multiplicative inverse (slow) or a source of randomness (footgun) for the nonce.
2. Hashes the public key into the signature in order to deliberately break linearity. Signatures with different keys will use different hashes, and hashing isn't linear, so adding the signatures no longer yields anything useful. The signature verifier checks this (they can, since they have your public key), so a defective implementation can't skip this step without producing bogus signatures.
EdDSA being deterministic, means it’s not Schnorr by definition.
The other difference of EdDSA is having a different keygen process: SHA512 then clamp the first 32 bytes (and this process breaks down all additive key derivation that’s nice to have) clamping is not the problem and you have to clear cofactors for Schnorr over that curve anyway, but it’s the hashing at the beginning that’s different and has nothing to do with cofactor clearing.
The other difference of EdDSA is not having a standardized verifier (keywords are “cofactored” and “cofactorless” verifier) and this breaks down another nice property of Schnorr signatures which is signature aggregation.
Overall the standards for EdDSA -unfortunately- still leave a lot to be desired.
There’s also a musig2 one by the same author.
Lol. Nice.