Re: Forward secrecy
hal@finney.org Fri, 04 August 2000 01:30 UTC
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02507 for <openpgp-archive@odin.ietf.org>; Thu, 3 Aug 2000 21:30:19 -0400 (EDT)
Received: by ns.secondary.com (8.9.3/8.9.3) id RAA07501 for ietf-openpgp-bks; Thu, 3 Aug 2000 17:58:44 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA07493 for <ietf-openpgp@imc.org>; Thu, 3 Aug 2000 17:58:42 -0700 (PDT)
From: hal@finney.org
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id SAA06859; Thu, 3 Aug 2000 18:00:12 -0700
Date: Thu, 03 Aug 2000 18:00:12 -0700
Message-Id: <200008040100.SAA06859@finney.org>
To: I.Brown@cs.ucl.ac.uk
Subject: Re: Forward secrecy
Cc: ietf-openpgp@imc.org
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>
A comment on http://www.ietf.org/internet-drafts/draft-brown-pgp-pfs-00.txt, "Forward Secrecy Extensions for OpenPGP". The ideas here are good, but I object to the inclusion of the one time pad as a new cryptographic method for OpenPGP. Although OTPs can provide forward secrecy, this is not their main purpose (which is to provide absolute secrecy). And to use them primarily for this purpose requires some care which the proposed mechanism doesn't really address. In particular, there is nothing in the proposal for distinguishing multiple OTPs, or for indicating which ones should be used for a given decryption. Also, there is no mechanism for selectively erasing just part of a given OTP. The assumption seems to be that there is one OTP, and it is used to decrypt one message, then it is deleted. Given the tremendous difficulty of distributing a OTP, this is not a practical mode of operation. But rather than fixing this up by providing OTP identifiers, storage modes, ways to keep track of which parts of a OTP should be deleted, etc., I think this whole section should be removed. It goes too far beyond the claimed scope of the document. Adding a OTP is a whole new area of functionality for OTP. It doesn't belong in a document like this, IMO. There are some other ideas you might want to consider. One is what has recently been discussed on the ukcrypto list, which is to provide a mechanism in the client to surrender selected session keys rather than public keys, under court order. This provides a minimal way of complying with the new UK laws. The document proposes that when you export a private key in the clear, it should be automatically revoked with an appropriate reason-for- revocation flag set. This is reasonable, although it is obviously easy to force someone to give you their key without triggering this mechanism, by having them export it encrypted but tell you the passphrase. Another idea along these lines is to have a mode to export the private part of only the subkeys, or perhaps a single subkey, while exporting only the public part of the top level signature key. Perhaps rather than triggering a revocation, it could set the bit in the self-signature key flags meaning "the private component of this key may be in the possession of more than one person". Then you'd want to have the clients display keys with this bit set in some special way. Another idea, which would be much harder to specify clearly, was something that PRZ proposed to me way back in 1992. Similar to the one-use decryption keys, he proposed that communicating parties cache a session key to be used over a series of messages, updating it for each message transfer. You could get forward secrecy by doing something like new_key = hash(old_key), with appropriate precautions. This would be a lighter weight mechanism than the one-use decryption keys, but it would be more of a change to the OpenPGP standard. Hal
- Forward secrecy Ian Brown
- Re: Forward secrecy sen_ml
- Re: Forward secrecy Ben Laurie
- Re: Forward secrecy Ian BROWN
- Re: Forward secrecy hal
- Re: Forward secrecy Will Price
- Re: Forward secrecy Ian BROWN
- Re: Forward secrecy Will Price
- Re: Forward secrecy Adam Back
- Re: Forward secrecy hal
- Re: Forward secrecy Ian Brown