From: Adam Back <aba@dcs.ex.ac.uk>
Date: Thu, 16 Oct 1997 21:53:42 +0800
To: kent@bywater.songbird.com
Subject: re. GAK resistant design principles: worked example #1
In-Reply-To: <19971015203509.42369@bywater.songbird.com>
Message-ID: <199710161339.OAA00277@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




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`