Re: [Cfrg] Threshold signatures

[Phillip Hallam-Baker <[e-mail]>]

OK so current state of play:

Multi-signatures are simple to create. But think about what it really takes
to verify them. We are going to have to specify a signature validation
policy which is of course a subset of the security policy problem.

I and many others are more than willing to do security policy. But there
are folk who reach for a hammer and some oak stakes.


The difference between the use cases I am considering and those that result
from the Bitcoin use cases is that they are operating under a particular
set of constraints and I am not.

Specifically, their concern is that they would like Alice Bob and Carol
with public keys A, B, C to be able to create ad-hoc compound signatures
that can be validated in a single operation under a public key f(A, B, C)
where f is a function that can be calculated by any observer.

My concern is that Alice Bob and Carol each have the ability to control the
creation of a signature under an aggregate signature key Z but do not have
the ability to create a signature without the necessary quorum of signers.
I do not require that the key Z bear any correspondence to A, B or C at all.


Boneh and co are calling the  f(A, B, C) signature an aggregate signature
and consider it as being distinct from threshold signatures. I believe that
is the correct approach and that we should adopt that nomenclature.

https://crypto.stanford.edu/~dabo/pubs/papers/aggreg.pdf

I am not surprised aggregate signatures require pairing for security. Is it
really likely that f(A, B, C) = A + B + C is going to give us the type of
security guarantee we are looking for?