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

Vincent Yu <v@v-yu.com> Sat, 15 March 2014 21:40 UTC

Return-Path: <v@v-yu.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A3B1A01AC for <openpgp@ietfa.amsl.com>; Sat, 15 Mar 2014 14:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uguRI7yfRaL9 for <openpgp@ietfa.amsl.com>; Sat, 15 Mar 2014 14:40:46 -0700 (PDT)
Received: from smtp10.hushmail.com (smtp10.hushmail.com [65.39.178.143]) by ietfa.amsl.com (Postfix) with ESMTP id 68E591A01BB for <openpgp@ietf.org>; Sat, 15 Mar 2014 14:40:44 -0700 (PDT)
Received: from smtp10.hushmail.com (localhost [127.0.0.1]) by smtp10.hushmail.com (Postfix) with SMTP id 30B5DC00F6 for <openpgp@ietf.org>; Sat, 15 Mar 2014 21:40:36 +0000 (UTC)
Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp10.hushmail.com (Postfix) with ESMTPS; Sat, 15 Mar 2014 21:40:35 +0000 (UTC)
Message-ID: <029427f6d271b61840ad3f919796c18c@smtp.hushmail.com>
Date: Sat, 15 Mar 2014 17:40:32 -0400
From: Vincent Yu <v@v-yu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Nicholas Cole <nicholas.cole@gmail.com>, openpgp@ietf.org
References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <a6d56e791a2c878f34369abc6f09b71d@smtp.hushmail.com> <5323146D.4050006@fifthhorseman.net> <a9cf1a7b7e08e0d601fa5c7c5cf50e71@smtp.hushmail.com> <5323DF28.5070809@fifthhorseman.net> <F4D2857E-0D33-4B6E-8829-9026CE9398DF@callas.org> <CAAu18hczJb9C2qv-HYJ0kwP7npEgy4f-D0VOMReBSi==XqT9Eg@mail.gmail.com> <CAAu18hc2BPd3u2OnvxMGattGrdEXZgpxTGsR05GU7D-7L10Usw@mail.gmail.com>
In-Reply-To: <CAAu18hc2BPd3u2OnvxMGattGrdEXZgpxTGsR05GU7D-7L10Usw@mail.gmail.com>
X-Enigmail-Version: 1.6
OpenPGP: id=d28d7c4078b3742a; url=https://v-yu.com/pubkeys/openpgp.asc
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TBqkS0j86Ev4AQQGGTUiFhoW9u3aR4mFv"
Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/eSAMXbHVwYj0Lo0-YKc5U005Tyk
Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Mar 2014 21:40:48 -0000

On 03/15/2014 04:40 PM, Nicholas Cole wrote:
> On Sat, Mar 15, 2014 at 8:33 PM, Nicholas Cole <nicholas.cole@gmail.com> wrote:
>>
>>
>> On Saturday, 15 March 2014, Jon Callas <jon@callas.org> wrote:
>>> Now on the other hand, ages ago, we discussed ring signatures, and a use
>>> case that I wanted to do was to make it so that whenever Alice sends Bob a
>>> signed email or other casual message, she would (could?) sign it with a ring
>>> signature of her key and Bob's. Bob knows that he didn't sign it so he knows
>>> that Alice did.
>>>
>>> Of course, it's one of those things that are cool, and yet it's hard to
>>> say what it actually does to improve anything.
>>
>>
>> It also breaks the metaphor of a 'signature' too: the signatures we
>> currently have work in a very similar way to the ideal real-world signature.
>> This type of signature doesn't: it is a signature only specific people can
>> verify, or rather, a signature that could have been made by any one of a
>> number of people. The problem might then become proving you were *not* the
>> person who made it, rather than the person who did, and proving a negative
>> is impossible. I think for that reason I'm not sure would welcome it being
>> added to gpg.  "Yes, that is a signature that I could have made, but I
>> didn't" is not an easy position...
>
> And thinking about it even further, it compounds a problem that
> someone (was it you, Jon?) has written about in the past.  Even though
> we all know that key UIDs can be signed by complete strangers, users
> are *often* disconcerted by this fact (which is why there is a
> no-modifier flag, even if keyservers have never respected it and even
> if it would make the use of OpenPGP even more complicated).  Still, a
> naive user of an OpenPGP program may draw incorrect inferences about
> social relationships from UID signatures.  Imagine the outcry of users
> if they discovered that documents were in the wild that 'might' have
> been signed by them...
>
> N.

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.

Vincent