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

john.dlugosz@kodak.com Thu, 11 April 2002 22:13 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 SAA16915 for <openpgp-archive@odin.ietf.org>; Thu, 11 Apr 2002 18:13:50 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3BM1rF23904 for ietf-openpgp-bks; Thu, 11 Apr 2002 15:01:53 -0700 (PDT)
Received: from kodakr.kodak.com (kodakr.kodak.com [192.232.119.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3BM1qm23900 for <ietf-openpgp@imc.org>; Thu, 11 Apr 2002 15:01:52 -0700 (PDT)
Received: from knotes.kodak.com (knotes2.ko.kodak.com [150.221.122.53]) by kodakr.kodak.com (8.11.1/8.11.1) with ESMTP id g3BM25p01639; Thu, 11 Apr 2002 18:02:05 -0400 (EDT)
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
To: vedaal@hotmail.com
Cc: ietf-openpgp@imc.org
From: john.dlugosz@kodak.com
Date: Thu, 11 Apr 2002 17:01:57 -0500
Message-ID: <OF4880F824.3763FAE2-ON86256B98.0078D941@kodak.com>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 04/11/2002 06:01:50 PM
MIME-Version: 1.0
Content-type: text/plain; charset="us-ascii"
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>


From: John Dlugosz

Beautiful.

A split isn't necessary, though.  Just make a key and have the private part
known to both.





"vedaal" <vedaal@hotmail.com>@mail.imc.org on 04-11-2002 03:43:56 PM

Sent by:  owner-ietf-openpgp@mail.imc.org


To:   <ietf-openpgp@imc.org>
cc:
Subject:  Re: Recipient-verifiable messages, was: forwarding an encrypted
      PGP message is useless




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