Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys

[Vincent Yu <[e-mail]>]

On 03/15/2014 06:02 PM, Nicholas Cole wrote:
>
>
> On Saturday, 15 March 2014, Vincent Yu <[e-mail] <mailto:[e-mail]>>
> wrote:
>     This reminds me that I used the name "signer-ambiguous signature" in
>     some of the early drafts of my proposal. This name concisely
>     describes the most important property of ring signatures. Now that I
>     think about it, that is a much better name than "ring signature" for
>     implementations to present to their end users.
>
>     "Signer-ambiguity" was coined by Rivest et al. to describe ring
>     signatures in their seminal paper in 2001, so it's well-connected to
>     the concept of ring signatures in the literature.
>
>     Unless there are severe objections, I will modify the proposal to
>     use the phrase "signer-ambiguous signature" to refer generally to
>     the signatures produced by the scheme, and use "ring signature" only
>     as technical term for the specific scheme that was chosen to provide
>     signer-ambiguity.
>
>
> I think that is a better name.  It gets away from the idea that there is
> a 'ring' of people who have authorized each other to make signatures.
>   But still, I think that this proposal will bring more problems than
> benefits.  Signatures will appear that 'might' have been made by all
> kinds of people on all kinds of documents.  User interfaces will
> struggle to help users to make good decisions as a result.  I can't help
> feeling that this kind of signature belongs in very specific
> applications, and not in general purpose tools. But I could be wrong.

I share your concerns, but on the whole, I think it is a net positive to 
offer signers the option to create signer-ambiguous signatures. Let me 
go into more detail.

Within benign use cases, there are two sides to signer-ambiguous 
signatures: the recipient's side and the signer's side.

The recipient would generally prefer to receive standard signatures 
rather than signer-ambiguous signatures because standard signatures 
offer stronger guarantees and grant them the power to prove to others 
what they received. However, recipients would prefer to receive 
signer-ambiguous signatures rather than no signature. So from the 
recipient's perspective, signer-ambiguous signatures can be bad or good, 
depending on whether the alternative is a standard signature or no 
signature.

However, signer-ambiguous signatures are designed with the signer in 
mind. The signer would find signer-ambiguous signatures useful in 
situations where they wish to ensure authenticity without granting 
recipients the power to transfer their signatures (here, I am 
considering only two-party communications; there are potentially other 
applications of signer-ambiguous signatures). Signer-ambiguous 
signatures are always good from the signer's perspective, because they 
provide an extra option that they may choose to use.

Within malicious use cases, there is the attacker's side. At the end of 
the day, a new signature type will indeed create a potential attack 
vector, and it is hard to predict exactly what types of attack will 
become possible because the details will depend on the interactions 
between users and implementations.

It seems to me that your worries fall mainly within scenarios with an 
attacker. Without an attacker, there is little reason to worry about 
verifier confusion because the goals of signers coincide with those of 
recipients: signatures are a way for signers to provide a guarantee to 
recipients. If it turns out that recipients get excessively confused 
over signer-ambiguous signatures, then signers will simply decide not to 
use them. In the long run, signers will adapt and use signer-ambiguous 
signatures only when they judge that the benefits outweigh the potential 
confusion.

So we need only worry about the potential for verifier confusion in 
scenarios with an attacker. Here, I think implementations have a good 
response available if attacks grow rampant: they simply refuse to verify 
signer-ambiguous signatures. Without the cooperation of implementations, 
attackers can do no harm.

That is the worst case scenario. However, I consider it unlikely that 
attacks using signer-ambiguous signatures will ever become common enough 
to outweigh the benefits to signers. Perhaps our intuitions differ here.

The main point I wish to reemphasize is that signers are free not to 
create signer-ambiguous signatures if they think that the potential for 
confusion outweighs the benefits. Their goals are aligned with those of 
recipients.

Vincent