Re: [Cfrg] Threshold signatures

Also, if just need signatures, why not do 3 normal signatures where each signature says "to be valid, there need to be 2 other valid signatures".  Or are you trying to enforce correctness via crypto (so that if only one signature, it can't be valid)?  If so, that is admirable, but unless something critical is encrypted, not achievable.

-d

> On Jan 3, 2020, at 8:42 AM, Tony Arcieri <bascule@gmail.com> wrote:
> 
> On Fri, Jan 3, 2020 at 10:04 AM Phillip Hallam-Baker <phill@hallambaker.com <mailto:phill@hallambaker.com>> wrote:
> At this point, I think we need to focus on making X25519/448 and Ed25519/448 the basis for the next gen of security products.. It took about five years from AES being announced as a winner for it to become the new normal. 
> 
> Given your stated goals of a multisignature which can work for both developers and things like HSMs and cloud KMS services, and code signing systems only supporting a single signature as opposed to threshold signature sets, I think it's worth questioning whether Ed25519 signatures are the right tool for the job.
> 
> I think draft-boneh-bls-signature might be a better fit as it supports offline aggregation. This means HSMs/KMS systems do not need to participate in an interactive protocol to produce a signature. It also facilitates offline/"airgapped" codesigning (using e.g. hardware tokens).
> 
> An interactive signing protocol where all of the participants must be able to reach a central online "broker" in order to produce a multisignature (and also all be online at the same time) is an onerous requirement, as opposed to one where each system can produce a signature and they can be retroactively aggregated.
> 
> -- 
> Tony Arcieri
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg