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

[Nicholas Cole <[e-mail]>]

On Sunday, 16 March 2014, Vincent Yu <[e-mail]> wrote:

> 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
>

I understand the two use-cases you outline, and why from a signer's point
of view the scheme can make sense.  But the original paper that introduced
this scheme was called, "How to leak a secret". This is a scheme
deliberately designed to throw suspicion on to others, so I don't think I'm
being too pedantic in insisting on thinking about attackers. The scheme was
originally designed so that a staffer in a political organization could
leak data to a third party but create doubt about who had done it.

I suppose you could argue that we just have to hope that such tools would
be used responsibly, or even that such signatures could be created with key
material that is already available.

I suppose I just get uneasy about a signature scheme that is designed to
deliberately throw suspicion on to third parties.

Have there been any attacks on the scheme?