On Tue, Feb 19, 2008 at 02:54:07PM +0000, Nicholas Cole wrote: > On Tue, Feb 19, 2008 at 1:23 PM, David Picón Álvarez > <[EMAIL PROTECTED]> wrote: > > > I know that ADK can be circumvented by a determined attacker, but it > > > strikes me as a useful feature, and I have never quite understood the > > > opposition to it. It would have made encryption more palatable in > > > corporate settings, which surely would have been a good thing! > > > > IMO there are two possibilities: 1) your users are forgetful but honest, 2) > > your users are dishonest. > > > > For case 1, an equivalent of ADK can be obtained with a line on GPG's > > configuration file. > > > > For case 2, you are screwed, and ADK is only going to give you a false > > sense > > of security. > > > > Thus ADK is either pointless or unnecessary. > > This just simply isn't true. > > Putting a line in a config file may be fine for internal mail, but > does nothing to help you to be able to decrypt mail sent from outside > your organisation. It also locks everyone into using gpg - I thought > the whole point of gpg / opengpg was to be inter-operative.
Let's define some terms, so we're all talking about the same thing in the same way. An ADK, for "Additional Decryption Key", sometimes called ARR for "Additional Recipient Request", is a packet that is added to a key. It is hashed into the key self-signature, so the key itself is needed to add it. This implies acceptance (or at least knowledge) of the existence of the packet by the key owner, and if nothing else, they can simply look at the key to see the ADK is there. (There was a bug a few years back where PGP accepted ADKs that weren't part of the self-signature, but that has been fixed). The main point of an ADK is to allow companies to get the benefit of encryption, but help avoid the big risk of an employee encrypting something in such a way that the company can't get it back. The employee could encrypt it and then quit (either maliciously or coincidentally), or encrypt it and lose their key, and so on. It's a real risk. The ADK contains two pieces of data: First, a key fingerprint. This is the key that the key owner is asking you to also encrypt to. Secondly, there is a bunch of flags that tell you how strongly the key owner feels about this. The key owner can say either "Please also encrypt to this key" or "You MUST also encrypt to this key". In use, an ADK is just another recipient. It's more or less equivalent to automatically adding a "-r the-adk-key" to a GPG command line. Finally, note that the ADK is *not* part of OpenPGP. It is a proprietary extension of the PGP product. It is also patented, which prevents those other than PGP from implementing it. (The PGP folks are actually very reasonable about interoperability issues, but as far as I know, nobody has asked about this.) Now, in a closed environment (say, internal email) where everyone is using PGP, it's great. Every message is also encrypted to the ADK key, and the company has assurance they won't lose any critical data. In a mixed (PGP + GPG) but still closed environment, it's still pretty good: those people using PGP will follow the ADK, and those people using something else won't. In the case of disaster, some data will potentially not be recoverable. This can be handled via the "encrypt-to the-adk-key" in gpg.conf method. To be sure, an employee in this closed environment could hack up something that doesn't respect the ADK. That's not a problem with the software. That's a problem with the employee. The more difficult case is a completely open environment (say, email for a company that also wants to encrypt their external email). In this case, those people using PGP will use the ADK, and others won't. It's not possible to require every external person to do what you want (they don't work for the company and have no reason to follow the ADK). In these cases, there isn't much that can be done aside from key escrow, or running some sort of mail gateway system that can be the keeper of the secret keys, or possibly even bounce messages back that don't have an ADK (eg "You won't use the ADK, so I'm not talking to you"). > But my real point is this: gpg in most areas says "This is a tool. > Your threat models will vary, and we give you a tool which you can > deploy". But in the area of ADK, even when for years people have said > on this list and elsewhere, "ADK would help with the > threat/organizational model we have", GPG refuses to help. "alter > your config file" solves (at best) half of the problem. Even if the patent issue was resolved, it doesn't really solve much to have GPG follow the ADK. GPG is distributed as source - easy enough for someone to simply comment out the ADK code if they didn't want it to take effect. David _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
