non-transferable sigs with hashes and encryption only (Re: Recipient-verifiable messages)

Adam Back <adam@cypherspace.org> Fri, 19 April 2002 02:40 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 WAA00024 for <openpgp-archive@odin.ietf.org>; Thu, 18 Apr 2002 22:40:13 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3J2Jt320997 for ietf-openpgp-bks; Thu, 18 Apr 2002 19:19:55 -0700 (PDT)
Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3J2Jr720993 for <ietf-openpgp@imc.org>; Thu, 18 Apr 2002 19:19:54 -0700 (PDT)
Received: from cronus ([144.173.6.20] helo=cronus.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 3.33 #1) id 16yO1x-00BAe4-00; Fri, 19 Apr 2002 03:21:45 +0100
Date: Fri, 19 Apr 2002 03:19:45 +0100
From: Adam Back <adam@cypherspace.org>
To: Hal Finney <hal@finney.org>
Cc: ietf-openpgp@imc.org
Subject: non-transferable sigs with hashes and encryption only (Re: Recipient-verifiable messages)
Message-ID: <20020419031945.A1943753@exeter.ac.uk>
References: <200204180158.g3I1wK729577@finney.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.2i
In-Reply-To: <200204180158.g3I1wK729577@finney.org>; from hal@finney.org on Wed, Apr 17, 2002 at 06:58:20PM -0700
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>

Hal Finney wrote:
> > The approach generalises to multiple recipient's: either hash in all
> > of the recipient public keys, or include signatures for each recipient
> > -- the latter is probably preferable as then the recipient doesn't
> > need all the other recipient's public keys to verify.
> 
> I don't think that works for multiple recipients, because any recipient
> can recover K, alter the msg, and re-create an apparently valid message
> that would be accepted by other recipients.  Alice's signature is only
> on K and public keys so that part doesn't change when the msg does.

You're right.  That doesn't work.  See below...

On Wed, Apr 17, 2002 at 06:58:20PM -0700, Hal Finney wrote:
> [...]
> 
> This concept can be applied pretty straightforwardly to the mathematical
> key-combining technique, I think (I figured out how to do it once) but
> I don't see how to use the simple hash/encrypt trick to accomplish this.

On the simple hash/encrypt approach, I think this should work:

Alice sending non-transferably signed message to Bob and Charlie:

Encrypt_Bob(K_B), Encrypt( K_B, Sign_Alice(K_B||Bob), H(msg) ), 
  Encrypt_Charlie(K_C), Encrypt( K_C, Sign_Alice(K_C||Charlie), H(msg) ), 
  msg

the message could optionally be encrypted using standard multiple
recipient technique (just include common key K):

Encrypt_Bob(K_B,K), Encrypt( K_B, Sign_Alice(K_B||Bob), H(msg) ), 
  Encrypt_Charlie(K_C,K), Encrypt( K_C, Sign_Alice(K_C||Charlie), H(msg) ), 
  Encrypt( K, msg )

The Encrypt() function should include MDC in both uses.


Bob can't transfer signatures as all he has is a signature that he
received a message from Alice and a random key.  He could forge any
message to himself with that information.

Similarly Bob and Charlie collaborating also can not transfer
signatures from Alice as they can collaboratively forge any message to
themselves.

As long as K_B is kept secret Bob is sure Alice sent him the message,
but can't convince anyone else of this fact.

Bob can't forge a message from Alice to Charlie with the information
he sees as he doesn't see Sign_Alice(K_C||Charlie), and can't
transform Sign_Alice(K_B||Bob) into that, and he doesn't know KC so he
can't decrypt to find out, nor can he modify the encryption because of
the MDC also keyed via K_C.

Adam
--
http://www.cypherspace.org/adam/