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