if i use a command like pgp filename it will automatically figure out the right thing to do with the file. if it's encrypted, and i have the key, it will attempt to decrypt it. if it contains keys, it will ask if i want to add them to my keyring. if it's signed, it checks the signature. this sucks! if i'm trying to write a program to automatically process incoming mail (for instance, to see if it's encrypted with a specific key), i certainly don't want to have the possibility of people being able to add garbage to my keyring just by mailing it to me. is there a way of saying pgp -decrypt-with-key user_id filename and have it return some error code indicating whether or not the file was in fact encrypted with user_id, and also gauranteeing that it won't do other fun stuff with the file, like add it to my keyring? is there a way of using pgp in a diagnostic mode, to just inform me of what the file contains (is it signed and/or encrypted, from who and to whom?), without processing it, and without interaction, and without messing around with the keyring? has anyone written some scripts to do this kind of thing? or should i just wait until some of the groups working on the other encryption software get it out? e
if i use a command like
pgp filename
it will automatically figure out the right thing to do with the file. if it's encrypted, and i have the key, it will attempt to decrypt it. if it contains keys, it will ask if i want to add them to my keyring. if it's signed, it checks the signature.
this sucks!
if i'm trying to write a program to automatically process incoming mail (for instance, to see if it's encrypted with a specific key), i certainly don't want to have the possibility of people being able to add garbage to my keyring just by mailing it to me.
... PGP suffers from its failure to separate cleanly its primary mechanism (encrypting and signing messages) from policy (what to do with those signed and encrypted mechansims). Without a clean separation, the mechanism is limited to use in those applications narrowly envisioned by the system's authors. Of course, PGP is hardly unique here; designing clean interfaces and separation-of- functions isn't easy, and its even harder in the face of meeting the needs of an existing installed base of first-generation users. Personally, I'd much rather see a suite of tools: an encryption/signature tool (or maybe tools - let me apply them in whatever order is approprate), a decryption verification tool, a certificate management system that operates on messages signed with the signature tool and a top level that glues all this together and implements local policy (like what consitutes a valid signature, key revocation, etc). If we had a system that worked like this,, we could more easily create richer key certificates that specify restrictions on what is being signed, revocation conditions, etc. (As it is, there isn't even any way for a key signer to revoke a signature, let alone describe what purpose the signature exists for.) Of course, you could probably build all this ON TOP of the existing pgp and pem, but you'd still be left with bloated underlying tools that implement more policy than they need to. Oh well. -matt
Matt Blaze says:
PGP suffers from its failure to separate cleanly its primary mechanism (encrypting and signing messages) from policy (what to do with those signed and encrypted mechansims). Without a clean separation, the mechanism is limited to use in those applications narrowly envisioned by the system's authors. [...] Personally, I'd much rather see a suite of tools: an encryption/signature tool (or maybe tools - let me apply them in whatever order is approprate), a decryption verification tool, a certificate management system that operates on messages signed with the signature tool and a top level that glues all this together and implements local policy (like what consitutes a valid signature, key revocation, etc). If we had a system that worked like this,, we could more easily create richer key certificates that specify restrictions on what is being signed, revocation conditions, etc.
I've been saying this for a long time, and I want to triple-reiterate it -- PGP needs to be broken down into simple Unix-philosophy style tools, or it isn't going to be useful in the long run. I'll also note, yet again, that unless PGP quits this bad practice of identifying counterparties only by a number, it is NOT going to be universally deployed. Counterparties need to be identified by a name that can be looked up in the DNS -- meaning "joe@foo.com" rather than some key ident number. Perry
"Perry E. Metzger" <perry@imsi.com> writes:
I'll also note, yet again, that unless PGP quits this bad practice of identifying counterparties only by a number, it is NOT going to be universally deployed. Counterparties need to be identified by a name that can be looked up in the DNS -- meaning "joe@foo.com" rather than some key ident number.
PGP of course looks up keys by strings in addition to numbers. A widely accepted practice is to use <joe@foo.com> in the user ID which allows the lookups to be by internet address. PGP was intended for use beyond the internet, such as in bbs's, fidonet, corporate networks, etc., where DNS style addresses may not be useful. Hal
Hal says:
"Perry E. Metzger" <perry@imsi.com> writes:
I'll also note, yet again, that unless PGP quits this bad practice of identifying counterparties only by a number, it is NOT going to be universally deployed. Counterparties need to be identified by a name that can be looked up in the DNS -- meaning "joe@foo.com" rather than some key ident number.
PGP of course looks up keys by strings in addition to numbers. A widely accepted practice is to use <joe@foo.com> in the user ID which allows the lookups to be by internet address.
The problem is that incoming messages are tagged with the number, not the string. You can't check the signature if you don't have the number in your own database. Global databases don't scale. Distributed databases like DNS do scale. DNS style naming doesn't hurt non-DNS users, so its a shame that it isn't there -- I, for one, can't specify PGP style keys in the internet key management system I'm working on because of this. Perry
Perry E. Metzger originally said the following...
I'll also note, yet again, that unless PGP quits this bad practice of identifying counterparties only by a number, it is NOT going to be universally deployed. Counterparties need to be identified by a name that can be looked up in the DNS -- meaning "joe@foo.com" rather than some key ident number.
Doesn't having some kind of central record of keys go against the principle of PGP? Unless you're just talking about having a name attached to each key, but not exactly a DNS for key id's... I'll admit I'm a little confused. ----------------------------------------------------------------------------- Greg Morgan <mac5tgm@hibbs.vcu.edu> | "I dunno Brain, me and Pipi Mail me for PGP Key: 0xE0D222A9 | Longstocking? I mean what would Key Fingerprint : 2430 BAA4 1EE4 AA2F | the children look like?" - Pinki 3B76 3516 3DEF 5529 | -----------------------------------------------------------------------------
Doesn't having some kind of central record of keys go against the principle of PGP? Unless you're just talking about having a name attached to each key, but not exactly a DNS for key id's... I'll admit I'm a little confused.
Not at all. The point is to have a centralized, distributed key distribution mechanism, similar in concept to the PGP Public Keyservers, but which scale much much better. The concept is similar to a DNS of PGP keys (think of the DNS model, not the DNS implementation) where you have keys distributed based upon site. For example, MIT could server MIT's keys, and CMU would server CMU's keys. This does not go against PGP in any way. In fact, it augments PGP wonderfully. How else would we be able to have a world-wide white pages of PGP Public Keys? -derek
On Fri, 10 Feb 1995, Derek Atkins wrote:
The point is to have a centralized, distributed key distribution mechanism, similar in concept to the PGP Public Keyservers, but which scale much much better.i
We already have a centralized, for profit, key distribution system. http://ww.four11.com/InfoServices.html If they make money off it, there will be more of them, they will provide better service, and it will in due course become a distributed key distribution system. Digression: I notice that it is possible to have thread titled "Why PGP sucks" without Holy Warriors leaping into the fray. This is a marked contrast with certain other topics. Possibly the level of heat is inversely proportional to the level of knowledge. (I.e. it is safe to have such a thread title because in this list we have many people with considerable knowledge of several different crypto systems, and who have spent considerable thought on the various possibilities.) --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.catalog.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the omnipotent state. | jamesd@netcom.com
Derek Atkins says:
The point is to have a centralized, distributed key distribution mechanism, similar in concept to the PGP Public Keyservers, but which scale much much better. The concept is similar to a DNS of PGP keys (think of the DNS model, not the DNS implementation) where you have keys distributed based upon site. For example, MIT could server MIT's keys, and CMU would server CMU's keys.
This does not go against PGP in any way. In fact, it augments PGP wonderfully. How else would we be able to have a world-wide white pages of PGP Public Keys?
Unfortunately, the current PGP practice of using only numeric key-ids in message packets makes it hard to do this -- sigh. I hope that the next version of PGP changes this. Perry
Unfortunately, the current PGP practice of using only numeric key-ids in message packets makes it hard to do this -- sigh. I hope that the next version of PGP changes this.
I doubt PGP will change this in the near future. That would require a major packet format change, and would not be anywhere near backwards compatible. I dont consider this to be a big problem. If you limit key lookups in the database to be lookup on userID only, that solves your database problem. As for the keyID->userID, well, this would only be required to _verify_ a signature. In that case, you know who sent the message to you so you can ask them for the key. When you want to encrypt to someone, you already know to whom you want to encrypt, so the same thing applies. I don't see the problem! -derek PS: I should state that I know what problem you are trying to solve, and I'm saying that there are other workarounds to get around the problem.
Derek Atkins says:
Unfortunately, the current PGP practice of using only numeric key-ids in message packets makes it hard to do this -- sigh. I hope that the next version of PGP changes this.
I doubt PGP will change this in the near future. That would require a major packet format change, and would not be anywhere near backwards compatible.
I dont consider this to be a big problem.
I do. It means that I can't use PGP for IPSP key management -- period.
If you limit key lookups in the database to be lookup on userID only, that solves your database problem. As for the keyID->userID, well, this would only be required to _verify_ a signature. In that case, you know who sent the message to you so you can ask them for the key. When you want to encrypt to someone, you already know to whom you want to encrypt, so the same thing applies.
I don't see the problem!
Sorry, but I see the problem. If I want to follow an arbitrary chain of signatures, check arbitrary signatures, etc, I'm forced to go through kludges or worse. I don't see it as acceptable to just ask someone for their key, either. Perry
Doesn't having some kind of central record of keys go against the principle of PGP?
The only "principle" of which I'm aware (and particularly interested in supporting) is that of having widely fielded, useful and strong privacy and authentication tools that work properly and transparently. That means, among a great many other things, flexible protocols and tools that support remote key distribution services. As much as people want to believe that privacy can be reduced to some kind of romantic struggle between the evil forces of Centralization (PEM?) and the civilizing forces of Anarchy (PGP?), the world most of us live in is a lot more complex than that. More seriously, the problem that Perry brought up is that it's hard to deploy any kind of scaleable key distribution infrastructure that works with PGP (as it currently exists - and yes, I realize there are work-arounds for some specific situations). That, as well as other shortcomings (like its fixed trust/certification model) that work against its serious use, make it doubtful that PGP 2.x has much long-term future as anything other than a plaything for nerds like us. Hopefully, PGP and other good tools will evolve to work well on a larger scale before Microsoft has a chance to give everyone what _it_ thinks the world needs. (I'm not trying to attack anyone here, by the way - part of the problem is that we're just now learning what the privacy problems of the real world even _are_. Experimental tools like PGP are important as much for providing experience and exposing problems and limitations as they are for their immediate function. Indeed, the fact that PGP and PEM are as useful as they are may actually work _against_ the spread of really large-scale crypto tools; the people who they are aimed at stay happy while the rest of the world never finds out what it's missing.) -matt
Matt Blaze <mab@crypto.com> writes:
More seriously, the problem that Perry brought up is that it's hard to deploy any kind of scaleable key distribution infrastructure that works with PGP (as it currently exists - and yes, I realize there are work-arounds for some specific situations).
Could you have a distributed database where you lookup by key ID and get a key? Or is there a constraint that the key distribution infrastructure has to be part of the DNS? I could see a set of key servers where one deals with all keys that start with 0x00, the next has all keys which start with 0x01, etc. This makes it easy to know which server to go to in order to look up a given key ID. Hal
Hal says:
Matt Blaze <mab@crypto.com> writes:
More seriously, the problem that Perry brought up is that it's hard to deploy any kind of scaleable key distribution infrastructure that works with PGP (as it currently exists - and yes, I realize there are work-arounds for some specific situations).
Could you have a distributed database where you lookup by key ID and get a key? Or is there a constraint that the key distribution infrastructure has to be part of the DNS?
I could see a set of key servers where one deals with all keys that start with 0x00, the next has all keys which start with 0x01, etc. This makes it easy to know which server to go to in order to look up a given key ID.
Theis will not work, Hal, because it would mean that administrative control over keys would have to be held by people far removed organizationally and spacially from those who own them. Things work much better when the administrators and users are close together. Futhermore, the DNS style solution scales -- it automatically aquires servers to meet demand as the space expands, unlike a pseudo-distributed system such as the one you propose. Furthermore, DNS is one of the few really large scale distributed databases that has been well proven, and piggybacking off the technology has real advantages. Perry
The only problem with piggybacking off the current DNS implementation is that DNS was designed for SMALL pieces of data (read: hostnames and IP addresses). PGP keys are HUGE pieces of data, in respect, and DNS just wont handle the sizes. For example, my PGP key is about 8k of data (approximately). DNS would never be able to handle that! It its bigger than a single UDP packet DNS has trouble. No, while DNS is a perfect model for a distributed keyserver, it is by no means the implementation infrastructure that we want to use. -derek
Derek Atkins says:
The only problem with piggybacking off the current DNS implementation is that DNS was designed for SMALL pieces of data (read: hostnames and IP addresses). PGP keys are HUGE pieces of data, in respect, and DNS just wont handle the sizes. For example, my PGP key is about 8k of data (approximately). DNS would never be able to handle that!
Well, its already been modified to do it. Read the drafts by Eastlake and Kaufman on DNS security, which basically means keys in the DNS and signed DNS records.
It its bigger than a single UDP packet DNS has trouble.
So you use TCP -- DNS already supports that. In any case, however, the reassembly size and lowest common denominator MTUs are being jacked way up for IPv6.
No, while DNS is a perfect model for a distributed keyserver, it is by no means the implementation infrastructure that we want to use.
I very strongly disagree. Even today, we find more and more bugs in DNS. If we had to start from scratch, we'd have to build an infrastructure like DNS all over again, only to find that we suffer from all the same old bugs and end up with a parallel implementation that looks almost exactly like DNS only less reliable. Perry
Matt Blaze <mab@crypto.com> writes:
More seriously, the problem that Perry brought up is that it's hard to deploy any kind of scaleable key distribution infrastructure that works with PGP (as it currently exists - and yes, I realize there are work-arounds for some specific situations).
Could you have a distributed database where you lookup by key ID and get a key? Or is there a constraint that the key distribution infrastructure has to be part of the DNS?
I could see a set of key servers where one deals with all keys that start with 0x00, the next has all keys which start with 0x01, etc. This makes it easy to know which server to go to in order to look up a given key ID.
Hal
Well, you could do that, but it has the disadvantage that you can't or control what server a particular key would end up on. One of the nice things about DNS-like systems is that a domain is responsible for providing the resources to provide lookups within it. If I add a machine to crypto.com, I add it to the crypto.com name server (plus the secondary servers, but that's a detail that gets handled automatically). Everyone knows to come here if they want to resolve a crypto.com name. In the case of PGP key IDs, you could create an artificial hierarchy of numbers for the purpose of offloading work among several servers, but that doesn't solve the hard problem, which is letting _me_ (or my designee) control (and be responsible for) the distribution of keys in _my_ domain. (When someone generates a new key it could end up anywhere in the kind of hierarchy you described). I don't think it's clear yet, by the way, that domain names are the right model for personal key distribution (in particular, it assumes that keys are being distributed on-line and deals only awkwardly with semi- off-line clients, as anyone who travels with a sometimes-networked laptop knows. It also assumes that the distribution hierarchy can be mapped atop the lookup keys namespace, which makes it hard to use for anything that isn't hierarchically formed). It's probably one of the important options, though, since it scales so well and has a successfully fielded history in DNS. -matt
Matt Blaze:
I don't think it's clear yet, by the way, that domain names are the right model for personal key distribution (in particular, it assumes that keys are being distributed on-line and deals only awkwardly with semi- off-line clients, as anyone who travels with a sometimes-networked laptop knows. It also assumes that the distribution hierarchy can be mapped atop the lookup keys namespace, which makes it hard to use for anything that isn't hierarchically formed). It's probably one of the important options, though, since it scales so well and has a successfully fielded history in DNS.
The idea I've had, and have floated to a few people, is not to base a distributed keyserver on DNS, but to use DNS as a model for a distributed key database. Hal, yes, you could have a keyID->userID mapping, but that doesn't scale well. Let me give you a concrete example (using DNS): I want the host information for TOXICWASTE.MIT.EDU. From the root servers I get to EDU->MIT->TOXICWASTE, and find its IP address (18.85.0.40). This would be like asking for a key by UserID (warlord@MIT.EDU would go to the MIT.EDU keyserver). Now, lets work in reverse, you have 18.85.0.40 and want to get the hostinfo. In DNS there is a 1-to-1 mapping of Domain to Network. You _know_ that any machine that is in 18.* will be at MIT, so again you can go to the MIT nameserver for help. This doesn't work with PGP KeyID, since the keyID is a random string of bits. As a result, you have no way to know that keyID 0xC1B06AF1 should be obtained on the MIT keyserver. This is the major problem that Perry is trying to address. I just don't know of a good way of doing this, other than maintaining a keyID->userID mapping table somewhere, but that can become a HUGE flat lookup table! James said:
We already have a centralized, for profit, key distribution system.
http://ww.four11.com/InfoServices.html
If they make money off it, there will be more of them, they will provide better service, and it will in due course become a distributed key distribution system.
No offense, James, but this needs to be a free infrastructure. When you get your shell account/IP address/PPP drop/etc., you should also automagically be allocated space in a keyserver. It shouldn't cost you anything to be put in it (just like it doesn't cost you anything to be put in the Telephone White Pages. The keyservers have to be distributed so that there is a single method for everyone in the world to connect to the white-page server of their choice. I'm sorry, but the WWW is not it. The WWW does not scale, and personally if I had to pay to be put on your server, I would ignore it; I'm perfectly happy using the Public Keyservers. Just as sites currently provide DNS service for names, they will, in some time, provide KeyService as well. It's just a matter of time. As for the "centralized" part... I think the distributed part is much more important. The public keyserver keyrings are currently over 3MB and growing. We need to be able to split that keyring across multiple servers and have requests go to the appropriate locations. Yes, there will be a centralized authority delegator, but the keys themselves, as well as the means to obtain them, will be distributed. Enjoy! -derek
Eric Hollander <hh@xcf.Berkeley.EDU> writes:
if i use a command like
pgp filename
it will automatically figure out the right thing to do with the file. if it's encrypted, and i have the key, it will attempt to decrypt it. if it contains keys, it will ask if i want to add them to my keyring. if it's signed, it checks the signature.
this sucks!
if i'm trying to write a program to automatically process incoming mail (for instance, to see if it's encrypted with a specific key), i certainly don't want to have the possibility of people being able to add garbage to my keyring just by mailing it to me.
In my remailer, I use: pgp -f < infile > outfile. This won't add keys. If you capture standard error you can parse it (grep is probably good enough) to see whether the message was signed, encrypted, had a bad signature, had keys, etc. Hal
if i use a command like
pgp filename
The problem is that you are using the wrong command....
it will automatically figure out the right thing to do with the file. if it's encrypted, and i have the key, it will attempt to decrypt it. if it contains keys, it will ask if i want to add them to my keyring. if it's signed, it checks the signature.
This is the correct behavior of "pgp filename". If you want other behavior, you should tell PGP how you want it to behave.
if i'm trying to write a program to automatically process incoming mail (for instance, to see if it's encrypted with a specific key), i certainly don't want to have the possibility of people being able to add garbage to my keyring just by mailing it to me.
A very noble effort, combining PGP with mailers. Btw: When you run "pgp filename" and filename contains public keys, it will ask you before it adds them to your keyring! You can use "pgp -d" to force it to do a decryption (although you cannot specify which key to use for the decryption; it will choose any of the keys on your secret keyring).
is there a way of using pgp in a diagnostic mode, to just inform me of what the file contains (is it signed and/or encrypted, from who and to whom?), without processing it, and without interaction, and without messing around with the keyring? has anyone written some scripts to do this kind of thing?
Well, I'm not exactly sure what you want. You can give PGP no password and it will tell you to whom a message is encrypted. You can call pgp -ka and it will _only_ add keys (and complain if you are given anything else). There is no way to ask PGP "what kind of message is this"; that is sort of what the ASCII ARMOR header is for.
or should i just wait until some of the groups working on the other encryption software get it out?
No, you should, at this point, consider working around the problems in the monolithic PGP, until a more modular library is available, to which multiple end programs can be built to do multiple little tasks, as Matt explained. Does this help? -derek
In message <9502102058.AA07955@josquin.media.mit.edu>, Derek Atkins writes:
if i use a command like
pgp filename
The problem is that you are using the wrong command....
hal pointed out to me that pgp -F will do exactly what i want. it will work. the behavior of pgp -F (given keys, for instance) is not well-described in the docs, but it will do what i want it to. as hal said, i can catch the stdout for the data, and catch the stderr for out-of-band info about the data, and this will work fine. and the product of all this is going to be quite cool. i'll post it when it's finished. e
if i use a command like
pgp filename
it will automatically figure out the right thing to do with the file. if it's encrypted, and i have the key, it will attempt to decrypt it. if it contains keys, it will ask if i want to add them to my keyring. if it's signed, it checks the signature.
this sucks!
From whose point of view? Remember the thread about Getting things right v. Getting the software out?
The above way is easier for most people with little computer techie knowledge. Requiring a whole complex set of commands would mean less PGP users. As people get used to it and learn about the issues, key management, etc. they'll be more willing to use a more advanced version of PGP... at the very least, they'll eventually RTFM and realize that you actally have more control of what it can do... Rob
if i'm trying to write a program to automatically process incoming mail (for instance, to see if it's encrypted with a specific key), i certainly don't want to have the possibility of people being able to add garbage to my keyring just by mailing it to me.
Have your program check what's in the mail before doing anything with it...?
participants (9)
-
Derek Atkins -
Eric Hollander -
Erich von Hollander -
Greg Morgan -
Hal -
James A. Donald -
Matt Blaze -
Perry E. Metzger -
Robert Rothenburg Walking-Owl