Some improvement to the advanced digital signature module #883
Conversation
- more accurate cert auth in web3. - verifier enforced → trivial multi-sig. - non-threshold → aggregated. - more accurate BLS verification speed claim.
| But we can still use certificates in some niche instances. | ||
| We are building systems that do not have a centralized "Certificate Authority".<br/> | ||
| But we can still use certificates: | ||
| - Certified by a distributed authority. |
There was a problem hiding this comment.
I think it is very important to get into the nuance on this topic if you mention it at this point. The main reason is that with a certificate authority, any and all certificates can be checked (largely) offline.1 However, in a distributed authority, there can be no single key.
For instance, If you want to trust something signed by the validators of a blockchain in a trustless way, you need to sync the whole chain up to the current state in some way, and then make sure that you get signatures from a secure majority of the current validators. Or make sure that the multisignature address (as that's much more likely than individual sigs) has been confirmed on the chain in some way, etc.
It's much more complex to use a certificate from a distributed authority than a CA.
I do like the other changes though, I agree niche was a bit excessive.
Footnotes
-
Not technically entirely true, due to things like checking databases for revocation certificates, checking the certificate transparency databases, etc. But fundamentally there is an offline chain of trust from the CA's hardcoded keys to the key providing them to you. ↩
| - Verifier enforced | ||
| - Cryptographic threshold | ||
| - Cryptographic non-threshold<br/>(a.k.a. signature aggregation) | ||
| - Trivial: union of individual signatures. |
There was a problem hiding this comment.
Union is often a confusing word for those not mathematically inclined. Can just call it 'sending multiple signatures'.
| @@ -95,7 +100,7 @@ Even in a web3 system, the verifier can be _distinct_ from the blockchain. 5 peo | |||
|
|
|||
| ### Cryptographic Multi-Sigs | |||
|
|
|||
| We want a succinct way to demonstrate that everyone from some set of parties have signed a message. This is achieved purely on the signer side (without support from the verifier). | |||
| We want a succinct way to demonstrate that everyone from some set of parties have signed a message. This could be achieved purely on the signer side (without support from the verifier). | |||
| @@ -190,7 +201,7 @@ However... | |||
|
|
|||
| - DKGs remain tricky (for threshold). | |||
| - Soft key derivations are typically insecure for BLS. | |||
| - Verifiers are hundreds of times slower than Schnorr, due to using pairings, for a single signature. | |||
| - Verifiers are significantly slower than Schnorr, due to using pairings, for a single signature. | |||
| @@ -202,6 +213,7 @@ Schnorr & BLS multi-signatures avoid complicating verifier logic,<br/>but introd | |||
| - DKG protocols | |||
| - Reduced key derivation ability | |||
| - Verification speed | |||
| - Proof of possession verification. | |||
There was a problem hiding this comment.
I'm assuming this is referring to the part of the musig protocol that avoids chosen-public key attacks? If so, I would just cut this as it is already covered in the communication-heavy DKG protocol.
There was a problem hiding this comment.
Even for simple aggregation (when you don't need to run DKG) with BLS signatures you still can forge other participants signature if you don't show PoP.
There was a problem hiding this comment.
Ah ok, good to leave it in then.
This will improve the advanced digital signature modules with few changes: