Non-transferable signatures with PGP -- extended abstract

Ian Brown and Adam Back

Non-repudiation is an important property of digital signatures made using public key cryptosystems. It allows agreements to be made that cannot be later disavowed by the contracting parties. It is less appropriate, however, for applications such as electronic mail. While you may wish the recipient of a private message to be sure it came from you, you may not be happy if they can prove what you wrote to anyone they choose.

Symmetric encryption implicitly 'signs' data. If Bob receives a message from Alice encrypted with a shared secret key only they possess, he can be sure that it came from Alice. He cannot, however, prove this to anyone else. Even if he gives the shared key and ciphertext to a third party, there is no way to prove it was Alice and not him that encrypted the message. By combining asymmetric and symmetric systems we can create non-transferable signatures that can only be authenticated by the user intended by the signer.

Public-key encryption can be used to share a secret between two parties. The secret can then be used to symmetrically encrypt data. Hybrid systems like PGP already use this technique to take advantage of the speed of symmetric algorithms. The secret itself is not authenticated, however.

If the symmetric key was signed, the message recipient could be sure who sent it. The encrypted message could only come from someone who knew that key. The recipient could therefore be as confident of the origin of the message as she was of the confidentiality of the message.

The recipient could attach the signed key to another message encrypted with that key, making it appear to be signed by the original sender. To prevent this, the key should be hashed with the recipient's public key before it is signed.

We have written software that can create and verify non-transferable signatures using PGP formats. Figure 1 shows how PGP 5 signs an encrypted message. It first takes a digest (MD5 or SHA1) of the message and signs this using the sender's private signature key. It then chooses a random session key and encrypts the signature and message using a symmetric cipher (IDEA, Cast or 3DES). Finally, the session key is encrypted using the recipient's public encryption key (RSA or Elgamal) and prepended to the message.

Our software works almost identically, changing only the signature data. Rather than the message digest, the symmetric key hashed with the recipient's public key is signed. We have created a new PGP data type, using a previously unused identifier, to hold the signed key. It is structured identically to PGP signature data, but will be ignored by other PGP software. The signed key in figure 2 replaces the signed hash in figure 1.

We plan to extend this software to support more complex types of non-transferable signatures described in [1]. They allow features such as verification with the signer's co-operation and group non-transferable signatures. We also hope to incorporate e-cash protocols so that there is a financial penalty for revealing a signature or message without the signer's consent.

All these signatures will give message senders more choice over how public their mail can be made.

NB PGP's encrypted data packet needs to be fixed to prevent data being insertable without detection to make our scheme work. The favourite suggestion so far on the ietf-open-pgp mailing list is to include a hash of the packet contents at the end of the packet.

[1] Markus Jakobsson, Kazue Sako and Russell Impagliazzo. Designated Verifier Proofs and Their Applications. EUROCRYPT 1996: 143-154.