On Wed, Oct 15, 1997 at 11:45:01PM +0100, Adam Back wrote:
Part of the problem in this debate I think is that I have proposed many alternate designs, with varying degrees of GAK-hostility.
Also I have been accused of using "lots of anti GAK rhetoric, but giving no proposals" by Kent.
Adam, you've tossed out half-baked ideas buried in several thousand lines of anti-GAK rant. None of them were thought through in terms of infrastructure impact. The idea of reencrypting the data strikes me as half-baked, as well -- I sit and wonder about the pass-phrase handling for the transient encryption keys that are changing on a daily or weekly basis -- or is there no pass-phrase -- is the key just stored on disk with no protection
I reject that claim. (I did use lots of rhetoric, but this was to try to impress upon those arguing for CMR of it's dangers. They do not seem to acknowledge them.)
The evidence seems to suggest that the PGP folks agonized pretty heavily over their design. A stupid attack such as yours is far more likely to cement resistance than it is likely to win cooperation.
I'll try in this post to steer clear of anti-GAK rhetoric. We'll instead take it as a given that pgp5.5 and pgp5.0 are GAK compliant because of CMR and that this is a bad thing.
Trying real hard...
Will is correct on one point: at the begining I had not properly thought one aspect through:
I suspect there are several other flaws you are now quite aware of...too bad, I hoped you had something. [...]
Design 1.
Instructions:
- scrap the CMR key extension
- store a copy of the private half of the users PGP encryption key encrypted to the company data recovery key on the users disk.
I work for a large organization, I have a unix workstation, an xterminal booting off a departmental server, and a Mac in my office. As is typical in large organizations, a system admin team takes care of all routine administration of my systems. They all have root, of course, and routinely do system upgrades and software installs on my Mac. Your solution doesn't seem to fit this environment very well... [...]
Recovery method:
Custodian of recovery key inserts recovery floppy disk in machine, decrypts copy of users private key, hands control back to user to choose new passphrase.
Must be a very special boot floppy, of course, otherwise I just subvert the floppy driver, feign forgetting my passphrase, and collect the corporate crown jewels. Or I hack into somebody else's system and corrupt their key... [...]
- what is stopping you implementing this
It's completely unrealistic.
- are there any plug ins which can't cope with this - are there user requirements which it can't meet - is there some fundamental flaw you think I have missed - can you see ways that this could be perverted to implement GAK (yes I can too, btw, but...) - are those ways logisitically harder for GAKkers to acheive than for CMR
Please be specific, no general waffle about understanding the complexities of balancing user ergonomics, user requirements etc.
Unfortunately, for real products you do have to consider these factors. [...]
Adam
[1] ==============================8<============================== GAK-hostile design principles
If we take the design goal of designing systems including confidentiality which are not GAK compliant, we can most succinctly state this design goal as the task of ensuring that:
- at no point will any data transferred over communications links be accessible to anyone other than the sender and recipient without also obtaining data on the recipient and/or senders disks
This is great.
We can then derive the design principles required to meet the design goal of a non-GAK compliant system with confidentiality services down to ensuring that:
principle 1: no keys used to secure communications in any part of the system are a-priori escrowed with third parties
principle 2: second crypto recipients on encrypted communications are not used to allow access to third parties who are not messaging recipients manually selected by the sender
principle 3: communications should be encrypted to the minimum number of recipients (typically one), and those keys should have as short a life time as is practically possible
Key lifetime is a major issue. Keys are either protected by pass-phrase, or vulnerable. Think about how you are going to generate new keys every day, or every week... Think about off-line composition of email -- I have a laptop, download my mail from the pop server, compose email. Now I can't store my friends public keys on my disk, because they expire every day. So I have to go to the public keyserver for every correspondent's public key -- if the keyserver is unaccessible I'm out of luck. This radically changes the expected semantics of email. -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html