Hal Finney <hal(_at_)rain(_dot_)org> writes:
Adam Back <aba(_at_)dcs(_dot_)ex(_dot_)ac(_dot_)uk> writes:
[CDR or "anti-GAK" design principles]
You do a good job of saying what you want to avoid, but not much about
what you want to accomplish! You are doing this to satisfy some kind
of market need for commercial access to data. What are the requirements
your design will satisfy? What do the customers need? You can't design
a system based solely on what it doesn't do.
So? Of course you can't design a system based soley of don't dos.
The instructions for using the principles are:
The principles are a set of negative "don't dos" to overlay on to the
normal cryptographic protocol and software architecture design
process.
Use your ingenuity and existing knowledge of cryptographic
primitives and good software design, user ergonomics, and user
requirements to design a system which meets your user requirements
while breaking as few as possible of the principles.
What the principles attempt to do is codify the pro-privacy
cryptographers natural tendencies to want to avoid implementing and
fielding systems which can be of use to GAKkers.
I have not seen any refutation of my demonstrations that pretty much
all of PGP's current functionality can be acheived within anti-GAK
design principles.
The most worrying of uses that your software could be put to by
GAKkers is as an implementation of a fully functioning GAK system in a
company like Iraq where the thought police will literally torture
citizens to death for non-government approved thoughts.
PGP Inc's CMR design could I think it is reasonable to argue is a
ready to roll GAK system. It could be installed by the Iraqi
government with force of law tomorrow. Each service provider installs
the PGP policy enforcer, and configures the "message recovery" key to
be "thoughtpolice(_at_)mil(_dot_)iq"; each business with a leased line is
ordered
to do as the ISPs, and individuals are required to use pgp5.0 or
pgp5.5 (either of which is GAK compliant).
Now the secret police can read all their citizens mail, and PGP will
have provided the technology. Does that make your collective chests
swell with pride? No it doesn't. It fills you with dispair, and
disgust that someone would so abuse your software, and so ignore your
well meaning recommendations about ethical business behaviour.
However your disgust and despair, and well meangings won't help
prevent the civil rights violations occuring in Iraq using your
software. Your well meaning won't help people in the US either, if
the USG adopts PGP and passes laws to do the same as I described for
Iraq. It could happen. If PGP is sucessful, and the OpenPGP standard
makes it to Netscape SSL like acceptance levels, and the OpenPGP
standard includes the CMR functionality, well you will have built the
GAKkers their dream system. Something with a smooth migration path
for GAK.
You will notice that Bruce Schneier forwarded a message to cypherpunks
where the GAKkers are quoteed already praising the functionality of
pgp 5.5 in proving them with GAKware.
If PGP on the other hand were to adopt the CDR system, and put their
energies in working out the design details, they would find firstly
that they can acheive all the necessary functionality, and that I and
Bruce Schneier, and Peter Trei, and lots of other people would stop
saying rude things about them. But more importantly, they would be
fielding a non-GAK compliant system, and a non-GAK compliant protocol
in OpenPGP, and that will do much more to save our collective bacon
from having our comms key word searched by the GAKkers than PGP Inc's
undubitably well meaning words of assurance of their good intentions.
Really, once you strip out the sarcasm, I am not at all denying PGP
Inc's good intentions.
The problem is: good intentions don't prevent GAK.
Albert Einstein designed the nuke. He was a nice enough guy, who
wouldn't have advocated nuking millions of people but that sure didn't
help prevent Hiroshima.
PGP, Inc. has made its design choices based on interaction and discussion
between people responsible for security, human interface, sales/marketing
and customer support, as well as the customers themselves. The lessons
which have come out of this include an emphasis on solutions which
people can use and which will work in the field. This means they have
to be transparent, easy to learn, fit into existing procedures, and
be reliable, as well as being secure. Systems which require extensive
retraining, new operational procedures, or which will hurt reliability
are not acceptable - they simply won't be deployed. That's the reality.
Of course, and you would use those considerations to balance the
"don'ts" in the design principles. An important consideration of the
design principles is that deployment of anti-GAK software wins;
therefore the design principles also state that you should do your
best to design systems which your users will be pleased with, which
they will buy. As a pro-privacy advocate in the crypto software
industry you therefore have dual moral obligation:
- to design systems which aren't GAK compliant
- to work your butt off making your user ergonomics so excellent that
you wipe out the competition
This is because your concern should be to ensure that the majority of
users are using non-GAK compliant software, so that the GAKkers will
find it more logistically difficult to install GAK; so that they will
have a hard time persuading users to switch to TIS
"voluntary/mandatory" GAKware. The won't switch because they love the
slick GUI, they won't switch because they don't want to be bothered
replacing their software, and a few won't switch because they realise
what the GAKkers are up to.
A system with forward secrecy on email and rapid turnover of
communications keys has some attractive security properties, but you
need to look at the other aspects of using it. How will it respond to
errors? How can companies guarantee that they will be able to decrypt
data when they need it? Can you assure that no data will ever be around
which requires a key which no longer exists, and can you do so not in
a theoretical world where everything works perfectly, but in a real
company where people make mistakes and forget things?
The forward secrecy is a separable issue, actually. And is a good
example of balancing anti-GAK design principles against ergonomics
etc. Personally I think you could acheive it without that much extra
effort with minimal to no ergonomic impact. We can argue about this
separately as it is not really the central issue.
The key points are that there should only be one crypto recipient of a
message, and that the key used to encrypt the message and that
compromise of either the senders and/or the recipients systems should
be required to compromise the message.
This clearly allows recovery of the message contents, because the
communications key can be stored encrypted to a recovery key on the
recipients disk.
With our current design, as I described earlier, we have data structures
which will enable people to easily replace encryption keys,
So? That is just as easy to do in any number of possible design
permutations without having GAK compliancy.
It looks to me like our current model supports the necessary feature
set for what you want to do, so I don't see any need for changes.
What _I_ want to do completely irrelevant. It matters not a fig what
I do tinkering with some scripts for my own amusement, or in selling
to 1% of the market. What matters is what PGP does in selling to 50%+
of the market, and what the OpenPGP standard says in being used by 90%
of the market. If the OpenPGP standard requires GAK compliancy we
have a serious problem.
I'm much more interested in persuading you personally, and PGP Inc
that what they are doing is GAK compliant, and that by switching to a
CDR design they can avoid this GAK compliancy.
My interest in OpenPGP is that in the event that we are unsuccessful
in persuading PGP of dangers of their CMR system, that we have a fall
back in being able to still make OpenPGP compatible clients which
aren't compatible, so that other companies can field systems which
aren't GAK compliant, and can achieve their corporate data recovery in
morally responsible ways. In this event I would be vying for the
other companies to flourish at the expense of PGP Inc going bankrupt.
The one new suggestion has been to have separate communication and storage
keys, but this has several problematic aspects. Unlike the distinction
between encryption and signature keys, where it is obvious whether a key
is being used properly, it is not at all clear whether a particular
function represents communication or storage. Consider the case of a
remotely mounted file system, where what looks like a storage operation
is actually travelling across a (possibly insecure) network.
That has nothing to do with the design of the way PGP implements to
the OpenPGP standard.
What that says is that if you are involved in design of VPN or IPSEC
products that they should also be designed with anti-GAK design
principles.
You have to develop a sense of proportionality about the significance
of each anti-GAK principle as applied to each communication you apply
it to.
Another example comes from the initial version of the Eudora API. When
that makes calls out to the crypto library to encrypt messages, Eudora
actually stores the message in a disk file, has the library encrypt that
to another disk file, then constructs the message from that output file.
It will look to the library like it is encrypting a disk file using a
communications key, a violation of this proposed security policy.
If the disk is NFS mounted it would be.
You have to apply some critical thinking to designing any system. So
it is with designing according to the anti-GAK principles. Having
sound design principles doesn't negate the need for critical thought
in any design field.
What are you thinking above? That GAK might be implemented by
governments forcing us to use GAK compliant replacements for SSH, for
IPSEC and VPN software, and thereby be able to snoop on your email?
Firstly it sounds kind of round-about approach, and secondly the
correct area to solve this problem is in the purchase of non-GAK
compliant IPSEC and VPN software. Or if PGP gets around to IPSEC in
the design of non-GAK compliant IPSEC software. (Don't tell me: PGP
would design IPSEC packets with GAK compliant CMR also?)
You have to apply the above sort of critical reasonsing, and balanced
evaluation of weak point of the system.
In fact, in most cases a storage key will not be a public key at all,
but will be a symmetric cipher key, such as with our own PGPDisk product.
When I was arguing for a separate storage key, I was thinking that you
would want a symmetric storage key. Perhaps pgp -c, or pgp -cs
functionality.
If you use the CDR method, and use symmetric storage keys, with
multiple storage recipients (one symmetric key (you), one asymmetric
company recovery key) for the stored mail folder, you have message
recovery.
Actually you could get away without storage keys as such, in that you
could store the recovery information for your encryption key on the
local disk. If you were to use this simple change and discard the
second enforced crypto recipient field (which breaks the second
anti-GAK princile) you could have the minimal set of modifications
needed to convert pgp 5.5 into an non-GAK compliant system.
See any specific flaws in that?
The only thing it does not allow is corporate message snooping. I
have yet to see a PGP employee admit that pgp5.5 is designed to meet
the user requirement of message snooping.
This allows transparent disk encryption and decryption. In that case you
really don't have "storage keys" as such in the public key infrastructure,
so there is no need for a distinction.
Yes. And that is the ideal system in my view. However I notice that
pgp doesn't have a PGPdisk for the PC, nor for any versions of unix.
I don't have a MAC. MACs are nice machines and all, but they don't
actly have the lions share of the market as IBM compatible PCs do. I
encourage you to develop disk systems for other platforms.
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(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`