Re: Recipient-verifiable messages
"David P. Kemp" <dpkemp@missi.ncsc.mil> Fri, 12 April 2002 23:00 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 TAA06298 for <openpgp-archive@lists.ietf.org>; Fri, 12 Apr 2002 19:00:17 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g3CMiXm25718 for ietf-openpgp-bks; Fri, 12 Apr 2002 15:44:33 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3CMiUm25714 for <ietf-openpgp@imc.org>; Fri, 12 Apr 2002 15:44:30 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g3CMhrX18609 for <ietf-openpgp@imc.org>; Fri, 12 Apr 2002 18:43:53 -0400 (EDT)
Message-ID: <200204122243.g3CMhrL18605@stingray.missi.ncsc.mil>
Date: Fri, 12 Apr 2002 18:44:58 -0400
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-openpgp@imc.org
Subject: Re: Recipient-verifiable messages
References: <200204111545.g3BFjdw11622@finney.org> <p0510153cb8dbc0a982fc@[192.168.1.97]> <200204120005.g3C05VL13758@stingray.missi.ncsc.mil> <p0510153fb8dbd86e1539@[192.168.1.97]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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
Jon Callas wrote: > The obvious difference is this: > > If the shared secret (shared by, say, Alice and Bob) used to generate a MAC > is leaked -- suppose Charlie learns it -- then anyone, Alice, Bob, or > Charlie can rewrite the MAC undetectably. > > On the other hand if Alice generates one of these signatures and sends it > to Bob, a third party, Teresa can verify the signature but: > > * not be able to create one of her own and > * cannot tell from the signature itself whether Alice or Bob made it. > > I'm not sure how useful it is in the real world, but it's a fascinating thing. > > I could sign a message to this list combining a dozen keys and thus create > a presumption that I made it without explicit demonstration of it. Thanks, Jon. I'm still missing something though. If the algorithm requires 1 private key and n-1 public keys to verify (so that only the recipients can verify it), then Teresa, not being a recipient of the original encrypted message but having a forwarded copy of the decrypt, would not be able to verify it. Thus by elimination you are talking about an algorithm that requires n public keys to verify, and anyone can verify that one of n people generated it without being able to tell which one. "Recipient-verifiable" seems like a misnomer for something that recipients and not-recipients alike can verify. Now assume that Alice gives something to Charlie, or a bug in her software allows him to steal it. Your job is to figure out whether Charlie got hold of Alice's private key or the shared secret that Alice derived from her private key and Bob's public key. There are two possible algorithms: a "signature-algorithm-that-is-not-a-MAC" that Teresa can verify, and a MAC function whose key input is derived from Alice's private key and n-1 public keys. What is the difference between those two algorithms with respect to what they tell you about what Charlie got from Alice? (Or what they tell you about any other question you care to ask?) In other words, the algorithm is a black box. You can't see it, you can only see the g'zoutas and you can do whatever you want with the g'zintas. Does the algorithm use a MAC or not? If it walks like a MAC and it quacks like a MAC, then ...
- 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