Kent Crispin has a tenacious ability to continue to think logically and critically, and not be drawn into emotional exchanges in the face of jibes and hostilities (I am referring to previous unpleasantaries on cypherpunks). I think we all could take a leaf out of his book. I am going to attempt to myself from this point on in the CMR vs CDR argument. (I accept Jon Callas comments along similar lines.) Kent Crispin <kent@songbird.com> writes:
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.
I have resolved to repent my ways with regard to unconstructive ranting and rudeness. This should have the positive side effect of reducing the length of my posts, and ensuring that more people read them critically. That the ideas seemed initially fuzzy is a reflection of the fact that I have, as I presume others have also, been gradually improving my understanding of these complex issues. I found the exercise in attempting to codify what I consider to be optimal design decisions from the point of view of maximising the GAK resistance properties of protocol designs, software implementations and communications standards useful in clarifying my thoughts. I feel confident in my ability to demonstrate that my GR (GAK resistant) design principles can be usefully applied to increase the GAK resistance of the design of systems using confidentiality and communicatons. I will comment on your specific comments on this aspect below.
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
Your suggestion that the re-encryption construct is weak from a GAK resistancy (GR) perspective is correct. See my earlier comments on realising the danger of that construct.
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 am forced to agree that emotional attacks are likely to hinder cooperation. Therefore emotional attacks on this topic are themselves likely to be counter to global GR optimisation. It is for this reason that I will attempt from this point on in this discussion to swallow my anger unless I can justify outbursts in terms of GR optimisation. Readers are encouraged to remind me if I start slipping. I can only offer as an excuse that it seems to me that PGP Inc could be doing more to increase the GAK resistance of their product and design within the financial and user requirement constraints they face. Emotional appeals are as you say is not likely to be the best means to explain this belief. I also offer as a mild excuse that in carrying out interactive list discussions with people in the US who are on GMT-8 that my sleep deprivation may have been showing through in irritability :-) I found myself for instance going to bed at 8.30 am the other night.
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...
Allow me to rephrase that in the light of my GR maximisation motivated apparent character reform: I believe that PGP Inc could make their design more resistant to GAK. The reason I believe that PGP Inc has thus far arrived at different design conclusions than I, Bruce Schneier, Tim May, Ian Brown, and others, is that PGP Inc have differently prioritised the multiple desirable properties of a socially progressive crypto design. Desirable properties are in prioritsed order of importance as I see them: 1. preventing big brotherish governments enforcing GAK 2. discouraging little brotherish business practices 3. encouraging transparency of intent (marking keys with statements of intent on handling of plaintext) 4. application ergonomics I think that PGP Inc has transposed criteria 1 and 2 in their prioritisation. I believe PGP Inc's design decisions and recommendations to companies reflect honest attempts to discourage little brother, and their use of statement of intent technology demonstrates their commitment to preventing big brother. But I fear that their prioritisation reduces the big brother resistance of their CMR system because this resistance has been traded off to attempt to provide little brother resistance. If I understand correctly several PGP employees have claimed that you should attempt to enforce the statement of intent principle with protocol modifications. Whilst statement of intent is useful, and a good innovation which I applaud, criteria 1 and 2 should take precedence where protocol modifications which are thought to strengthen statement of intent have a side effect of reducing GAK resistance. Independently I think that it is not semantically useful to try to enforce statement of intent at the protocol level with the CMR method. This is because having an enforced second recipient in no way guarantees that the second recipient will read the message, or is able to read the message (the second recipient might not receive the ciphertext, or he might have lost the company access key).
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.
I believe that using the GAK resistant design principles allows one to focus more clearly on the benefits of the various trade-offs possible and to more acurately prioritise the multiple social criteria.
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.
Sounds like a good example to base discussions upon: X-terminals, multi user unix work stations and remotely configurable PCs.
Your solution doesn't seem to fit this environment very well...
I would take your point there to be that you can't store the recovery key on the local disk for the reason that the disk isn't local, and that when the recovery key is stored on the local disk on remotely administered or multi-user workstations that this is less secure. I agree. It is less secure. (I have htmlized, and attempted to more clearly re-word the GR design principles: http://www.dcs.ex.ac.uk/~aba/gakresis/ I have also added a fourth corollary which you might like to comment on (it's not relevant to the above point).) To return to your criticisms based on the mish-mash of shared user and X-terminals typical of corporate environments, corollary 2 expresses the best that can be done in this scenario:
Corollary 2: where communications are transmitted in ways which violate principles 1, 2 or 3 it is in general more GAK resistant to enforce as far as possible that the recovery or escrow information remains in as close proximity to the data as possible, and as much under the control of the user as possible.
So if you are using an X-terminal, your passphrase will be going over the ethernet, and all the files will be on a unix box. About all you can do about this to minimise security problems is to try to secure your ethernet with IPSEC technology. This is not currently very widely deployed especially for intranet use. Certainly if you are using your X-terminal to connect to machines over the internet many companies have taken steps to reduce the dangers of this. VPN systems, and SSH achieve this kind of thing. IPSEC and VPN technology are typically fairly GAK resistant anyway, because use of forward secrecy is common. The overall system is _still_ more GAK resistant than CMR for the sorts of logistical reasons that Tim May has been describing. You may like to comment on this claim which I am willing to defend.
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...
You can hack around it, and this is implicitly acknowledged. The point is that in trying to design the system so that it must be hacked around before allowing easy use in a mandatory GAK setting you have built in extra GAK resistance in the form of the deployment and logistical problems the government will have in developing, and deploying patches and making sure every one applies them.
[...]
- what is stopping you implementing this
It's completely unrealistic.
It was stated in it's simplest possible form for clarity. It is however possible to build resistance into the system in the form of inertia of the deployed code base in not providing automated ways to access the recovery information outside of the software package. Bill Stewart came up with the very good suggestion for example that you only keep some of the bits of the recovery key to ensure that recovery appears is artificially made time consuming. This means that with out replacing your software base, the government has a much harder time installing GAK. This also has the social benefit of discouraging companies from using what are intended to be data recovery features as snooping features. This is exactly the sort of lateral thinking that I am hoping to encourage.
- 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.
I fully agree that you have to acknowledge user ergonomics and user requirements. What I was asking was that people in criticising my GR design principles explain which user requirements they think can not be met, or which user ergonomics features are hindered. I also explicitly state in design principle 4 that you should balance these considerations to maximise the global GAK resistance of the deployed software and hardware in the target jurisdiction.
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...
Perhaps if I give some examples of how some one designing a protocol according to these principles might proceed in this direction it would be clearer how to minimise the impact on ergonomics without losing security to the extent that it allows government access simply as a property of the induced weakness. (In otherwords I am willing to trade security for extra GAK resistance if it comes to it, but typically does not seem to be required as GR design principles 1, 2, and 3 are independently sound security objectives). Companies would protect all keys by password, or by smart card token, or by secured facilities or just by the nature of it being sufficient for their security requirements to rely on the same weak physical security which protects their paper files. So: the signature key does not have recovery information -- I think this is agreed by all. The storage key used in encrypting information on your disk is has recovery information stored as described. The shorter lived forward secret keys could be also recovery protected (during their lifetime). PGP 5.x already has this feature. Consider the encryption keys to be your forward secret keys. Give them shorter than normal expiry dates. Your next comment is very pertinent in demonstrating the sorts of problems you must work around in attempting to maximise use of forward secrecy.
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.
I have 2 comments on this problem: Consider: a system which automatically adapts and is forward secret when it is able but not when it is not possible is more GAK resistant than one which never uses forward secrecy at all because of the existance of some situations where it is difficult to use. Consider also: a system which is relatively forward secret (perhaps with key updates every week, or month) is more GAK resistant than one which makes no frequent key recommendations and leaving people to choose long expiries of 1 year or with user no comments made on the dangers of not having expiries at all is more dangerous. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`