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`