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
- Recipient-verifiable messages, was: forwarding an… Hal Finney
- Re: Recipient-verifiable messages, was: forwardin… vedaal
- Re: Recipient-verifiable messages, was: forwardin… john.dlugosz
- Re: Recipient-verifiable messages, was: forwardin… john.dlugosz
- Re: Recipient-verifiable messages Jon Callas
- Re: Recipient-verifiable messages David P. Kemp
- Re: Recipient-verifiable messages Jon Callas
- Re: Recipient-verifiable messages David P. Kemp
- Re: Recipient-verifiable messages, was: forwardin… Adam Back
- Re: Recipient-verifiable messages, was: forwardin… Hal Finney
- Re: Recipient-verifiable messages, was: forwardin… Hal Finney
- Re: Recipient-verifiable messages, was: forwardin… Adam Back
- Re: Recipient-verifiable messages, was: forwardin… Hal Finney
- Re: Recipient-verifiable messages, was: forwardin… Werner Koch
- non-transferable sigs with hashes and encryption … Adam Back
- Re: Recipient-verifiable messages, was: forwardin… Bodo Moeller
- Re: Recipient-verifiable messages, was: forwardin… Bodo Moeller