Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless

"vedaal" <vedaal@hotmail.com> Thu, 11 April 2002 21:09 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15069 for <openpgp-archive@odin.ietf.org>; Thu, 11 Apr 2002 17:09:40 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3BKuhN21961 for ietf-openpgp-bks; Thu, 11 Apr 2002 13:56:43 -0700 (PDT)
Received: from hotmail.com (oe17.law3.hotmail.com [209.185.240.121]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3BKugm21954 for <ietf-openpgp@imc.org>; Thu, 11 Apr 2002 13:56:42 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Apr 2002 13:45:32 -0700
X-Originating-IP: [207.127.12.210]
From: vedaal <vedaal@hotmail.com>
To: ietf-openpgp@imc.org
References: <200204111545.g3BFjdw11622@finney.org>
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Date: Thu, 11 Apr 2002 16:43:56 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Message-ID: <OE17NY30kkZIhTrBoe20000072b@hotmail.com>
X-OriginalArrivalTime: 11 Apr 2002 20:45:32.0196 (UTC) FILETIME=[D28FA640:01C1E199]
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Hal Finney" <hal@finney.org>
To: <ietf-openpgp@imc.org>
Sent: Thursday, April 11, 2002 11:45 AM
Subject: Recipient-verifiable messages, was: forwarding an encrypted PGP
message is useless
...

> I proposed a different method, which basic idea is expressed in a paper
> by Rivest, Shamir and Tauman, "How to Leak a Secret", available from
> http://theory.lcs.mit.edu:80/~rivest/publications.html.  This paper shows
> how to produce a signature which can be verified to be from a specific
> list of keys, but you can't tell which key on the list made the signature.
> It is very simple and efficient for RSA keys.  I think extensions are
> possible for discrete log keys, but the paper doesn't cover that.
>
> For the recipient-verifiable signature, Alice would create one of these
> multiple-signer signatures based on exactly two keys, Bob's and hers.
> Anyone can verify that the resulting message has been signed by Alice or
> Bob, but there is no way to tell which.  Alice then sends the message
> to Bob.  He knows that he didn't sign it, so it must have been Alice.
> But if he shows it to someone else, all they can see is that either
> Bob or Alice signed it, so Bob could have created a signature like this
> for any message he wanted.  Again there is no way for Bob to show the
> message convincingly to a third party, and Alice is protected.
...
> Unfortunately I think that adding a new flavor of signature would tend
> to create confusion among users who at best barely understand public
> key cryptography.  The new kind of signature would have very different
> security properties and usage scenarios, so it would add additional
> complexity for people to deal with.
...

no new signature type is needed.
this can be done now with a split key setup, for either an RSA or DH key:

Alice or Bob produces a new key  'Alice&Bob'

the share is set for 1, and the 'Alice&Bob' key is split with a share to
Alice's key, and a share to Bob's key,

either Alice or Bob can now sign with the 'Alice&Bob' key, without anyone
being able to detect whether it was Alice or Bob,
and  it will verify as a good signature from the 'Alice&Bob' key.

the 'Alice&Bob' split key can be imported into gnupg and the signatures
verified,
but gnupg cannot (yet) rejoin, sign or decrypt with a split shared system


if this is worthwhile/necessary, perhaps it could be considered for addition
to the gnupg system.


hth,
vedaal