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. 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.) 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.
Will is correct on one point: at the begining I had not properly
thought one aspect through: my earlier decrypt & re-encrypt construct
violates anti-GAK design principle 2; namely it is guilty of the same
violation as CMR, it has an effective second crypto recipient outside
of the senders control. I agree with Will Price's comments on the GAK
pervertability tendencies of this construct. I spotted the error of
my ways since clarifying my thoughts on the subject by constructing
the more formalised anti-GAK design principles. Readers will see my
codification of my recognition of the dangers of the re-encrypting
construct in corollary 1 of the anti-GAK design principles (copy of
principles below ). The fact that I posted this corollary in
updated copies of the design principles prior to Will's post should
show that this claim is sincere and not an attempt at side stepping
Will's observation: he is correct, I agree.
The rest of Will's post seems to miss the point, so it seems to me
that the best way to transfer understanding of how to use the anti-GAK
design principles to design less GAK friendly systems is to present a
This first simple CDR replacement for PGP's CMR method also attempts
to keep changes necessary to implementations and packet formats to a
minimum. Please understand also that it violates one of the major
design principles in order to acheive this simplicity and so that
objections that it is not that much more valuable than CMR will be
countered by showing you how to achieve an even more GAK-hostile
design by removing the violation of design principle 3, albeit with
more coding effort and design modifications on PGP's part. Never the
less it is already much harder to pervert for GAK than CMR.
- 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.
- (optional) design the software to make it hard to copy the data
recovery packet from the disk, hide the data, bury it in keyrings,
stego encode it, whatever, use your imagination. This is to attempt
to restrict the third parties ability to by pass the principle of
non communication of recovery information
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.
objection #1. what if disk burns?
counter #1: backup your disk
objection #2: users don't back up disks
counter #2: that is a good way to loose data :-) if they don't have
the data the key protecting the data won't help them
Harder to pervert for GAK than pgp5.5 / pgp5.0 CMR design.
I'd be interested to see Will, or Hal, or other PGPer's criticisms of this
simple modification, perhaps criticisms could most constructively answer:
- what is stopping you implementing this
- 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.
That is a no-brainer, you need to do this analysis, the cost function
for evaluating such design issus is now expressed explicitly in design
principle 4 rather than being assumed. List problems and explain the
significance of the all important deployability criteria.
Cryptographic protocol designs are very flexible; most design goals can
be met, or worked around I claim within the positive GAK-hostility
side of the cryptographic protocol and product design solution space.
Lastly, I would encourage readers to be critical of the GAK-hostile design
- can you see any aspects which inaccurately reflect trade-offs
- can you see methods to bypass inadvertently or deliberately the design
that might require another corollary to correct.
In anticipation of constructive criticism,
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 with out
also obtaining data on the recipient and/or senders disks
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:
no keys used to secure communications in any part of the system are
a-priori escrowed with third parties
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
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
deployment wins. violating any of principles 1 to 3 whilst
still retaining some GAK-hostility can be justified where
deployment is thereby increased to the extent that the violations
increase the degree of GAK hostility in the target jurisdictions
Corrollary 1: Included in design principle 2) is the principle of not
re-transmitting keys or data after decryption over communication
channels, re-encrypted to third parties -- that is just structuring --
and violates design principle 2.
Corrollary 2: where communications are transmitted which violate
principles 1, 2 or 3 it is in general more GAK hostile to enforce as
far as possible that the recovery or escrow information remains in as
close proximity to the data as possible.
Corrollary 3: where communications are transmitted which violate
principles 1, 2 or 3 it is in general more GAK hostile to make these
communications as difficult to automate as possible. For example no
scripting support is given to enforce that GUI user interaction is
required, and/or that the process is made artificially time consuming,
and/or that the communication must not use electronic communication