From: Adam Back <aba@dcs.ex.ac.uk>
Date: Sun, 12 Oct 1997 07:21:14 +0800
To: randerso@ece.eng.wayne.edu
Subject: the case for separate comms keys
In-Reply-To: <3.0.2.32.19971011155857.0069ea28@ece.eng.wayne.edu>
Message-ID: <199710112231.XAA05916@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Ryan Anderson <randerso@ece.eng.wayne.edu> writes on cpunks:
> Adam Back <aba@dcs.ex.ac.uk> writes:
> >You should have 3 types of key:
> >
> >1. signature keys
> >2. transient encryption keys
> >3. storage keys
> >
> >The transient encryption keys are for communications, you delete them
> >immediately after use.  Yes I'm talking forward secrecy here.  If you
> >don't like forward secrecy, well at least don't escrow the encryption
> >keys.
> 
> Huh?   Okay, PGP uses IDEA for transit keys.  These are encrypted to two 
> different PGP public keys. [...]  These are only used once.

The security principle I am referring to is that by doing as PGP
currently does, and using encryption keys in place of separate
communications and storage keys you are exposing your past traffic to
undue risk.

I am not at all referring to symmetric keys, because the fact that
they are randomly generated and used once doesn't protect them from
recovery via the compromise of your long encryption key and your
attackers copy of your encrypted communications.  The reason for
randomly generating IDEA session keys is a separate one.

The argument for having separate storage and communication keys is a
similar one to the now accepted argument that it is a good idea to
have separate signature and encryption keys.  The obvious advantage of
separating signature keys from encryption keys (introduced in pgp5) is
that if you escrow keys you don't want to escrow signature keys as all
this enables is forgery.

> The signature keys (in the proposed method) are the PGP keys (either
> RSA or DH, it's not important) are the personal keypairs of each
> person.  The company doesn't keep a copy of these.  They can sign
> with this in an unforgable manner.
> 
> Is there a problem here?

No.  I wasn't discussing signature keys.

> - From the description Jon gave of the system, you can designate
> anyone as the other key-id to encrypt to in your signature block.
> (Or whatever that part of the key is called).  The guy in the next
> cube, your boss, one company-wide key, etc.

Yes.  That's half of the story.  The other half of the story is that
PGP went ahead and implemented a SMTP snoopware policy enforcer which
could just as easily be used to enforce GAK.

> So yes, in theory this could be used to implement GAK.  Supposedly
> in the version of PGP in use it's trivial to remove this extra
> recipient from the list of encryption keys.  

I'm not sure that the fact that the pgp5.0 client doesn't attempt to
force you to use the GAK compliancy key adds much to my comfort level
that the whole thing won't end up being used for mandatory GAK.  My
scepticism is derived from the fact that the enforcement of the GAK
compliancy key is provided by another marvelous PGP Inc big brother
innovation: the SMTP snoopware/GAK compliancy policy enforcement app.

The argument doesn't really become apparent until you consider the
effects of lots of people (say 80% of companies) using PGP's GAK
compliancy enforcement.  A few more thin edge of the wedge moves on
the part of the USG GAK proponents (eg deputising service providers as
GAK compliancy enforcers, something which has already been discussed
in the past with the Clipper series), and you will suddenly be unable
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).

> 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.

> When you compalin about use of storage keys/communication keys your
> clouding the issue.

It might appear complex, but actually adding the distinction between
communications and storage keys greatly simplifies things, and it
allows you to make more appropriate security decisions about key life
times, and escrow.  It also allows you to implement the message
snooping function in a more secure way, and with less big brotherish
overtones.

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

> The storage keys can be (and probably are in some cases) simply pgp
> encrypted files, as if they were in transit.  

Storage keys could be symmetric keys if they are for your own use
only, or you could escrow them if you want to share access, or your
company wants the extra assurance of data availability that storage
key escrow brings.  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.

> I tend to encrypt some files on my hard drive with pgp, by
> encrypting to myself and signing so that onyl I can decrypt them,
> and I've got record that I did create the archive.

You can sign and encrypt with symmetric keys also. "pgp -cs."  Quite a
useful combination.

I used to do the opposite of what you do... I used to use pgp -cs,
because I explicitly didn't want the public key baggage, and danger
that 1024 bit keys might be readable in 10-20 years, the then maximum
key size.

> I can see this being done in a company to simplify shared storage
> usage without security problems.  Using the multiple recipient
> option your recovery key-id can be used to decrypt these files.  Of
> course, if they're modified, they can't be resigned, so you'd know,
> but...

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.

You could use multiple crypto recipient if you wanted to -- it's
basically just another way of acheiving the same thing.

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.

If the company keeps it's employee's storage keys in escrow, the fact
that you're using a symmetric key works fine.

> This is a *simple* solution that eliminates problems with encrypting
> hard drives, etc.

I don't see that it's any more difficult to do as I outline above,
which is better security practice in any case.

> Where is the problem with this system?  This is software that
> (according to Jon's claim) at least one company has decided they
> need for their security, and it keeps the number of pass phrases
> that employees need to memorize at one - their PGP key.

Don't confuse key functionality with user ergonomics.  PGP or other
vendors could easily implement a unified interface to a secured
private key database containing all of your persistent private keys.
You need only have one key.  Or perhaps no keys -- in a secured
environment, or with keys stored on smart cards.

> >Storage keys you make damn sure you can recover.  You escrow these for
> >real.  Company safe sounds about right.  Secret splitting could be
> >nice also.
> 
> Why not just encrypt it to yourself with PGP?  Isn't that simpler?
> Add a recipient of the recovery id.  Boss, coworker, person's key in
> another division, whatever.  Everybody gets different storage keys.
> No need to worry about accidently compromising one of the storage
> keys (IDEA symmetric keys, of course).  You then just need to keep
> the secret halfs of the public keys secure.  Not a big deal if you
> have the rest of the system working.

I'm not really fussy beyond the fact that it will be less efficient in
space (extra public key packets would be significant for a disk block
level partition encrypter), and the performance issues with using
public key crypto to encrypt lots of files to multiple people. 

> >You shouldn't be recovering transient messages, you should be
> >recovering stored data.
> 
> What the hell is the difference?  Speed of recovery?

Nope speed of recovery is not the issue.

> Give an example of the difference between what he's doing and what
> you would propose. Otherwise you're just rejecting this system
> blindly.

I'm sure I've given these reasons earlier in the thread, but I'll
summarise them again:

1. It is more secure to use short lived communications keys because
communications keys are more sensitive than storage keys.  This is
because with communications your attacker has copies of your
ciphertext as you're sending it over an insecure open communications
medium.  Your storage data is on your hard disk, possibly in a secured
environment.

2. People shouldn't be able to recover the data from communications
because for security reasons it should be encrypted with transient
communication keys.  You are purposelly securely wiping the key after
some period.  Keeping extra doors into the communication weakensn this
protection.

3. given that secured communications are now defined as transient in
nature, for security reaons: the natural way to archive such
communicated data is to re-encrypt it for a storage key.

4. people don't really want access after the fact to their transient
communications, they want access to their archived email.

5. you can still implement corporate snooping, and I acknowledge that
businesses have a right to do this (though personally I may not choose
to work for a company which does this).  But you can implement message
snooping, by implementing key escrow of the storage key used to secure
your email archives.  To enforce this to the extent that you can, you
build in automatic archiving in a way which is hard to defeat in the
mail client to decrypt communication with the comms key, and then
re-encrypt with the escrowed storage key.

6. Given the marked difference in life time, security requirements,
and data availability requirements between stored data and transient
communications keys is it any wonder that you can achieve a more
flexible, more secure system by separating functionality of your keys
-- it really is a very similar argument as to the argument over why
you should have separate storage and communications keys.

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`