why pgp sucks

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

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

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

>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

>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

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

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