ietf-smime
[Top] [All Lists]

Re: Difference between SMIME and PGP

1998-11-09 18:56:04
At 05:20 PM 11/4/98 +0100, Stefan_Salzmann/HAM/Lotus(_at_)lotus(_dot_)com wrote:
   
   I am struggling on the difference between SMIME and PGP. One of my
customers
   wants to make the decision between using SMIME and PGP. I have been talking
   already with them but we got stuck in detailes.
   
   Basically its quit clear. SMIME will be supported by all important industry
   leaders such as Netscape, Microsoft, Novell etc. 

I'd like to note that PGP is supported by NAI, Microsoft, Novell, and more
that are coming soon.

   Further SMIME supports the
   hierarchical trust model and PGP only supports the "web of trust" model. 

Actually, this is false. PGP supports all trust models, direct trust,
hierarchical trust, and web of trust. As I said in my previous message, PGP
supports 255 levels of hierarchy.

However, I forgot to say that OpenPGP does not mandate *any* trust model.
As a matter of fact, the OpenPGP working group has rejected any mandate of
trust model. You are permitted to use an OpenPGP certificate with PKIX
evaluation rules, and still be OpenPGP compliant!

   Now
   with PGP Version 6.0, PGP will support also X.509 certificates. Those
can also
   be loaded into an PGP client than an SMIME Client can do it.
   So where is the difference now? Is it just the fact that the industry
decided to
   go with SMIME or are there more differences (advantages for SMIME) when
looking
   more closely.

Actually, the industry hasn't decided to go with anything. Furthermore,
there is no reason why you can't have PGP messages backed by X.509
certificates, and it is trivial to use S/MIME with OpenPGP certificates.
I'm planning on writing a short informational RFC on how to do it once we
all get RFC numbers for our respective systems.

   For instance using RSA public key encryption versus Deffie Helman public
key
   encryption. How about Digital Signature Standard (DSS)? I have red about
DSS and
   understand that DSS is the standard that provides the Digital Signature
   Algorithm. Before applying it there has to be calculated an Digest using
SHA. I
   always thought that calculating the digest would be the signature
already!! So
   why using the DSA in addition? Will the digest be decrypted using the
Deffie
   Helman private key? 

The issue of algorithm is orthogonal to message encoding. The PGP-S/MIME
question is really one of message encoding format. Each requires DSS, and
allows RSA.

The DSS (Digital Signature Standard) describes how to make a signature
using DSA (Digital Signature Algorithm) and SHA1 (Secure Hash Algorithm).
That's how they relate. You could (for example) use DSA with RIPEMD-160,
but it wouldn't be DSS because DSS specifies the hash algorithm you should
be using for the signature.

DSA is a signature-only algorithm. Consequently, you aren't doing a
"decryption" with it when you evaluate a signature. I recommend you look in
a crypto source book, like Schneier's "Applied Cryptography" or Menezes,
van Oorschot, and Vanstone's "Handbook of Applied Cryptography" for details
of how DSS is done. There is also source code available from a wide variety
of places.

   Users that apply Deffie Helman exchange their public values
   in order to derive an secret key that will be known at both party sides.
Is that
   secret key the private key used to encrypt message digests or is the
private key
   generated by the DSA algorithm?

Like I said, DSS has its own signature-only key. As for "Diffie-Hellman"
depending on the variant of DH you're using, you may or may not have an
actual key. Many real-time systems use ephemeral DH merely to exchange
symmetric keys. In OpenPGP, we use the Elgamal system for encryption.
S/MIME is using an X9.42 algorithm that is very close (if not identical) to
Elgamal.

   In PGP further exist key rings that contain the public keys of other
users? How
   does that work with X.509 Certificates that actually contain the public
key. If
   there has to be a public key revoked, it happens in the key ring. Would
it be
   possible to export that revoked certificate. If not the revoked public
key would
   resist only lokally.

Most systems, be they PGP or X.509, use something akin to a directory to
store certs, revocations, etc. Typically, these are HTTP or LDAP based
systems.

   Are there any differences/advantages between RSA and Deffie Helman?

Again, this is orthoganal to encoding, as these are merely algorithms. But
yes, of course. The security of RSA is based upon the difficulty of
factoring large numbers. Most people who toss around the term
"Diffie-Hellman" use it to cover an entire family of algorithms whose
security is all based on the difficulty of solving discrete logs. These
include DSA, X9.42, Schnorr, and Elgamal. They are all approximately of the
same strength.

There are also a wide variety of advantages and disadvantages. Frequently,
these are the same. For example, in RSA encryption and signatures are the
same, which is simple, but leads to some hygenic problems. A signature-only
system like DSA is less flexible, but easier to export, and enforces good
key hygene (meaning that it is bad practice to use the same key for
signatures as for encryption). I could go on with a discussion of all this,
but this thread is already off-topic for this mailing list. Feel free to
mail me privately or phone.
   
   You see I am very confused right now and I have the feeling that all my
security
   theories woun´t match with those used in PGP.

There are many good reasons for being confused. One of the most important
ones is that there really aren't a lot of differences between the systems.
They are all trying to solve the same problem, but each has a slightly
different slant to it.
   
   I really would appreciate it if there would be someone helping my to
remove all
   that dust of my mind...
   
   Thank you in advance

You're welcome.

        Jon   

-----
Jon Callas                                  jon(_at_)pgp(_dot_)com
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

<Prev in Thread] Current Thread [Next in Thread>