From: Adam Back <aba@dcs.ex.ac.uk>
Date: Sun, 12 Oct 1997 21:10:34 +0800
To: randerso@ece.eng.wayne.edu
Subject: Re: the case for separate comms keys
In-Reply-To: <3.0.2.32.19971012063205.006e7b34@ece.eng.wayne.edu>
Message-ID: <199710121258.NAA01459@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Ryan Anderson <randerso@ece.eng.wayne.edu> writes:
> At 11:31 PM 10/11/97 +0100, Adam Back wrote:
> 
> >to exchange mail with anyone without using GAK.  Sure you have a
> >"choice", you can send email to people that will bounce 100% of the
> >time, whoever you send to due to lack of GAK compliance field.
> >(Except for perhaps a few die hard cypherpunks).
> 
> My reading of Jon's post was that the SMTP policy enforcer only worked for 
> outgoing messages.  Perhaps that's wrong, but that needs to be double-
> checked.  See below as well...

I'm fairly sure this is not the case.  The reason I think that this is
not the case is because Jon described two flags which go in the GAK
compliancy sub-packet:

Flag1:  this flag is an advisory note to the person who obtains a
	public key which has the GAK compliancy self signature
	sub-packet; it tells the person about to use the key that the
	company the person who owns this public key works for would
	like it if you would "please" encrypt to the contained
	corporate snoopware master key.

Flag2:	this flag is the same as the flag1 above plus it is a big
	brotherish/little brotherish warning that if you _don't_
	encrypt to the GAK compliancy key also, that the recipient
	will not receive the message.

I understood the reason that the recipient will not receive the
message when you don't honour keys with flag2 to be that the SMTP
policy enforcer would either bounce the message, or eat it, or send it
to the company snoopware czar to who can take due note in his employee
dossier collection that this employee is receiving email from
suspicious cypherpunk persons who don't believe in snoopware.

The above functionality is the reason I'm arguing that PGP's method of
implementing corporate snoopware is GAK compliant: clearly the whole
system is ready tailored for GAK.  The only thing left to do is plug
in the governemnts key in the GAK compliancy field, and for the
government to mandate that companies, and deputised ISPs use the
software and the GAK master key.

If/when this GAK compliancy gets used as the architecture for real
live mandatory GAK, the SMTP policy enforcer may be set up to narc out
the suspicious person who doesn't believe in GAK to the Feds/NSA, and
they will then come and lock you up if they can trace your SMTP From
field to you.

This will make a mockery out remailers, because the remailer chain
will also be forced to have the GAK master key in it as enforced by
deputised ISPs running PGP's SMTP policy enforcers with GAK keys
installed as the GAK master key. 

> >> It's not even needed if you don't have that key on your ring.  (From
> >> what Jon said)
> >
> >I'm not sure what you mean here.
> 
> The snooping key.  If it doesn't exist on *my* keyring.  (Say I have your 
> key, but not the key designate as your snooping key...)  [BTW: Forgive the 
> English, I'm tired and speaking in choppy sentences]

Oh, I see what you mean.  The reason I didn't understand is that this
is not how I thought it works.  I think the key is provided right
there in the GAK compliancy field in an inseparable way.  (I could be
wrong on this, but this is the way I read Jon's message).

Even if have misunderstood the way that this key is bundled, it
doesn't really alter the fact that by "choosing" not to encrypt to
messages with the flag2 flag you will know that this is a waste of
time, because your message will not get past the SMTP policy enforcer.
So purposely stripping the key from your key ring, or separating the
key pair when someone sends you them together would just be another
way of exercising the choice PGP is claiming you have in "choosing" to
have your message bounced back at you.  A fairly meaningless "choice".

I would be interested to have this point about the way GAK compliancy
key is bound/bundled with the GAK compliancy sub-packet clarified by a
PGPer, or someone with more understanding of the draft docs, if this
much information is available yet.

> If I have your key, but not the other key that I'm also supposed to
> encrypt to, PGP (whichever versions, I'm not entirely sure how the
> feature set breaks down, but I believe this applies to all versions
> of 5.x) will not even mention that there was another key it would've
> have offered to encrypt to.

I don't think this is so because that would invalidate the semantics
of the flag1 and flag2 flags, which are what instructs PGP to warn you
of this requirement for this key.  The flag is an attribute of the key
itself, though I do suppose you might be able to strip off the
attribute in much the same way as you can remove signatures from keys
with pgp -krs.

> >Using separate storage keys allows you to:
> >
> >- escrow storage keys within your company without including GAKware
> >  compliancy
> >
> >- discard communications keys often (by giving them short life-spans)
> >  which greatly enhances your security
> 
> Greatly complicating the "web of trust" method, but..  

I don't think it complicates web of trust.  The only certification you
need of communications keys is for you to sign them with your
signature key.  Your signature key semantics, and the web of trust is
unchanged.

> You can only chain signatures so far before you run into problems,
> and getting people to continuosly recertify could be a major pain,

It will be automatic .. you won't notice because all the OpenPGP
compliant application which supports this proposed (strongly
encouraged MAY, please!) feature will do when it creates a new
communications key is to sign the communications key with your
signature key.  It won't involve third parties re-issuing
certificates.

It is the same way that certification and WoT interacts with
potentially shorter life-span dual use encryption keys at the moment.
The WoT certificates go on your longer life signature key, and it is
you who signs your encryption key.  Same argument, though now applied
to encryption keys marked as "communications only".

> >There might be some security advantages to using
> >symmetric keys even.  (Public key sizes are a faster sliding and more
> >uncertain target than symmetric key sizes.
> 
> Well, at least with RSA keys, I believe the memory requirements to
> handle current factoring algorithms are quite untenable for 2048 bit
> keys.  I think 768 is out of the range of current systems.

512 bit I think is reckoned to be feasible for an academic crack of
similar scale to the recent RSA challenge DES break.  The memory for
the final matrix crunching phase might be the only arguable point.

However, this doesn't really give me 20 years worth of assurance
because, well Rivest and friends encrypted the message "squeamish
ossifrage" back in 1977 or thereabouts, firm in the belief that it
would not be broken for 1000s of years.  Factoring advances have meant
that that ~380 bit keys (squeamish ossifrage was RSA129 digits
decimal) is now relatively easy.  Paul Leyland and friends broke a 384
bit blacknet key as a private attack without massive internet
collaboration.

I'm not sure anyones promising, or has any mathematical proof that new
factoring algorithms won't provide similar factoring speedups.  How
many years are 1024 bit RSA keys good for?  All you can use as
estimators is the current factoring algorithms.  I'm not sure how
certain these estimates are for long term purposes.

In contrast if there is nothin wrong with 3DES nor IDEA, the key space
protects you, modulo Moore's law which is easier to predict.  (Also
modulo quantum computing break-throughs, in both cases, erk!)

> I think this came up on the RC5 (Bovine) mailing list, and the
> figures for the required server was something absolutely ridiculous.
> To distribute the job using the more efficient algorithm required
> machines with 128 meg of ram, but the slower one was a bit more
> doable.

Yes.  But memory on workstations is increasing in leaps and bounds.
It is very common now for personal PCs and even laptops to have 32Meg.
A few years ago we were living below the 640k barrier.  Leave it a few
years, and people will have the required memory levels.  A few more
years on from that people will be grizzling about living below the 4Gb
barrier (restriction from using 32 bit addresses).

Anyway, one of the factoring gurus may come up with another novel
implementation or algorithm tweak to tune down memory requirements.
Or a newly discovered faster factoring alorgithm may have huge memory
advantages over current alogirthms.

> In short, I don't think 2048 RSA keys are reasonable target in the
> forseeable future.  [Remember, Moore's law is only applicable for
> another 12 years or so.  Then quantum mechanics starts to be a
> serious problems, and electrons start switching channels in the
> chips.]

The future is uncertain.  But it is marginally less uncertain for
well tried and tested symmetric keys ciphers.

> But this is a bit of a wandering topic now.  Let me continue...
> 
> >You can sign and encrypt with symmetric keys also. "pgp -cs."  Quite a
> >useful combination.
> 
> Hmm.. I must've missed that.  

Don't think it says it anywhere, but you can combine flags in lots of
logical ways which aren't documented as such, and most of which work
as you might reasonaly extrapoloate them to.  There are single letter
flags for most letters of the alphabet, the full number of
combinations must be quite large.  Quite a few of them mean
*something*.  Some of them are even phonetically pleasing: -feast etc :-)

> Well, I wasn't really encrypting anything I really cared about.  It
> was backups of autoexec.bats and config.syss, I just wanted another
> copy that I *knew* when it was made, it wouldn't get overwritten,
> and it wouldn't get modified without me knowing.  And I needed
> something to use PGP for, so...

Signature only might've been enough for backups of stuff in plaintext
on the disk like autoexecs.

> In all honesty, the public key baggage is 512 bytes ( I think,
> possibly bits.  I've forgotten now ) Quite insignificant if you're
> dealing with CAD drawings.  

Sure.  But you were also talking about autoexecs and other small files
where it could get significant.  The significant lose howver is the
performance -- say you recursively encrypt all the files in a
directory, each to 2 or 3 multiple crypto recipients.  It'll crawl.

> >It's probably simpler to just escrow storage keys.  That is just give
> >management a copy to put in the fire proof safe.  Or secret split or
> >whatever.
> 
> I was actually thinking something along the lines of creating a file
> - encrypting it to your whole workgroup, and leaving it on a server.
> Now you have the advantage of not having any security problems even
> if the server is compromised [without workstation compromise, of
> course], and all the important people can access it.  Of course, the
> last person to modify it resigns it, and it gets dropped into your
> RCS system.

I see.  Sounds reasonable.  You should be able to achieve that with
the current dual use PGP keys, or with the new "storage only" keys via
crypto recipients.

If your document is on the Internet, on the web perhaps, you'd need to
be aware of the reduced security in using long term storage keys as
opposed to short term communications keys, but other than that I can't
see a problem.

The point is that where you have a directional communication, you
should treat those keys as sensitive.  Where it is not a directional
communication, you can't, so you lose that extra security; for
applications where this is acceptable, I wouldn't argue for
restricting your ability to do it.

> you get the added advantage of being able to rotate your keys here
> as well, so even if one key is compromised, and the server is
> compromised, you don't lose the whole system.  Identical argument as
> for communications keys.

I think I understand what you're saying for shared storage keys.  But
I don't think it's an identical argument at all for communications
keys.

If you define communications keys as short lived highly sensitive
keys, as perhaps in SSL, or SSH (both of which use some forms of
forward secrecy), you can't retain the ability to recover the message
after the fact for security reasons.

However I posit that people don't really want access to the plaintext
stored inside encrypted communications for their own purposes for the
simple reason that they don't have a sendmail log including all the
message bodies.

Together with the security advantages of not being able to decrypt
communications traffic yourself after the fact, this argues that
people who do want full email archives for company legal or snooping
purposes, or just folder for their own use (I know I keep lots of
email in folders) can either store in the clear, or store encrypted
with a storage key, or store with an escrowed storage key, or store
encrypted to multiple storage keys as crypto-recipients as you
suggest.

> >There is one (quite practical) reason, however, to use symmetric
> >storage keys.  Speed.  If you're encrypting lots of files (perhaps
> >using an encrypted parition driver such as Peter Gutmann's SFS), you
> >won't have time to encrypt to public keys, never mind multiple public
> >keys.
> 
> That's a different problem.  For that you're [in this ultra-theoretical 
> world] 

I don't think it's that theoretical.  Don't PGP have such an encrypted
disk driver for the MAC?  I think this is the way forward for simpler
storage encryption: encrypt the lot.  Saves arguments about forgetting
to encrypt stuff, or forgetting you did decrypt and leaving plaintext
copies around in /tmp or whever as well.

> probably going to want something along the lines of this: Symmetric
> encryption for speed on the partition, and that key stored with
> several recipients in the same place as the Secure Partition Driver
> (SPD).

Your suggestion is one reasonable way of acheiving this.  You can also
acheive the same flexibility with an extra indirection with symmetric
storage keys (optionally held in escrow).  In fact I think this is
what later versions of Peter Gutmann's SFS do.  The reason he uses for
this is that it allows you to change your passphrase without
re-encrypting the whole disk, because the _actual_ disk encryption key
is encrypted itself with the hash of your passphrase, rather than
using the hash of the passphrase directly as the key.

> (This falls in the, "If you're going to build a system, make sure
> you think of everythign you want and make sure it fits in the
> framework somewhere" method)

Well I agree, I think it's reasonable for us to consider the major
uses, plaintext recovery demands, and security aspects of the
different types of uses for keys: transient communication keys,
storage keys, and signature keys.

> >If the company keeps it's employee's storage keys in escrow, the fact
> >that you're using a symmetric key works fine.
> 
> I'm not sure you need to escrow anything, as long as there is a way
> to share things among certain groups of people.  Jon's ideas of
> non-hierarchical recovery systems seem a lot more secure anyway,
> especially with the rest of this thread.

It doesn't really matter one way or the other.  You can build
non-hierarchical recovery systems with either method.  (You can escrow
storage keys in your department, just as easily as add second crypto
recipient within your department.  I think the security is basically
the same for escrow or multiple recipient when we're talking about
storage.

The same security equivalence argument applies if you accept the
premise that you need access to transient communications.  I don't
accept this premise.  This premise is a fallacy promulgated by the
likes of Freeh.  If you don't escrow communications keys at all you
gain extra security for the same reason that it is less secure
actually to escrow storage keys, or use multiple recipient as another
way to achieve storage key escrow than to not use storage key escrow.
However with storage you live with this because a) data availibility
is important, and b) the risk isn't as great with storage because your
attacker has to breach physical security to obtain the data from your
disks and tapes.

> Oh - for the situation with Andy Grove (Intel CEO) describe earlier on this 
> thread - let me give this suggestion:
> 
> 	AG's key w/extra encryptions to CFO (or Pres. of Board, or
> someone else with significant influence and a close working
> relationship.  Backup for problems with intransit e-mail.)
> 
> 	Similar setups for everyone else in the company.  Probably the
> top-level executives all have AG as the backup.  This elminates
> snooping entirely in the company, on the top level execs.  This
> partially hierarchical method wouldn't be horrible, and limits
> snooping to the level above you, or to peers, depending on setup.

The suggestions about snooping heirarchy -- who can read who's mail
within the company -- are independent of which architecture you choose
to use to allow access to the mail (escrow storage keys or use
multiple crypto recipient for storage keys).  (This can all be
enforced with similar levels of resistance to bypass by building the
archive and snooping features into the mail client to do this after
decryption).

Where you start to get argument from me is when you start unduly
exposing what should be transient communications keys to construct
this corporate snooping pecking order.

> >I'm sure I've given these reasons earlier in the thread, but I'll
> >summarise them again:
> 
> Yeah, you covered them fairly well, and cleared up the issues where
> I honestly thought it was a fear-mongering problem.  I still don't
> completely agree with you, but we've clarified the problem areas.
> Thanks.

That's what it's all about -- meaningful discourse so that we can
collectively improve each others understanding of the problems at
hand, pointing out flaws in each others arguments until we reach
agreement, eliminating misunderstanding.  With that a clarified
picture of the security issues and best architecture, we can then go
on to design suitable security protocols which best reflect this.

> (Too many wars get *way* too religous on the net.  Let's try and
> avoid that here, ok?)

Hey, as long as we steer clear of PGP arguments about mandatory GAK
compliancy, this is all friendly discourse :-) 

On religious arguments: I must admit to strong negative feelings about
PGP Inc or the OpenPGP standard using weaker security methods to
enable GAK compliancy.  My reason for expressing these opinions is the
hope that we can talk PGP out of this big brotherish SMTP policy
enforcer, and associated GAK compliant fields, and to give my input to
try to steer the OpenPGP process away from incorporating said GAK
compliancy field into the standard.

Also as I hope I have explained relatively clearly in my other post
titled:

	Subject: negative security aspects of GAK compliance

that GAK compliancy is independently from political arguments a
security design flaw.  And so I think that we should be able to reject
it on technical grounds alone as a design with weaker security.

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`