From: Ryan Anderson <randerso@ece.eng.wayne.edu>
Date: Sun, 12 Oct 1997 18:41:26 +0800
To: Adam Back <aba@dcs.ex.ac.uk>
Subject: Re: the case for separate comms keys
In-Reply-To: <3.0.2.32.19971011155857.0069ea28@ece.eng.wayne.edu>
Message-ID: <3.0.2.32.19971012063205.006e7b34@ece.eng.wayne.edu>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----

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

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

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.

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

Greatly complicating the "web of trust" method, but..  You can only chain 
signatures so far before you run into problems, and getting people to 
continuosly recertify could be a major pain, but I can see the point you are 
making.   It got clearer.


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

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

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

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.  

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

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

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.  The added benefit of reducing passphrase uses is quite significant 
(with current PGP versions, the database of keys is a better idea actually).  
Possibly more portable across a range of users as well.

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

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.

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.

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

That's a different problem.  For that you're [in this ultra-theoretical 
world] 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).  (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)

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

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.

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

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.  (Too many 
wars get *way* too religous on the net.  Let's try and avoid that here, ok?)


-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQCVAwUBNECnJDc3ytqHnNyNAQGzAAP/bnYQQKdBnTY5HKc2fNlMYefYwZhdNXZo
aYNDhmybGM8756SIp0uuKaaf1t2f22is1/XdxaN2aHO+5qyHSc/EwgV4tWeQ1SXt
zBhMBM4phbTFSHl8FJUdRI9qcMxfoIfdoyJ5/CuYo83gJBwsrov6NZQylAlRR66K
VUAohcY/BxM=
=t0mO
-----END PGP SIGNATURE-----


-----------------------------------------------------------------------
Ryan Anderson - <Pug Majere>     "Who knows, even the horse might sing" 
Wayne State University - CULMA   "May you live in interesting times.."
randerso@ece.eng.wayne.edu         
PGP Fingerprint - 7E 8E C6 54 96 AC D9 57  E4 F8 AE 9C 10 7E 78 C9
-----------------------------------------------------------------------