
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`