PGP vs GPG - New findings.

[Fairlight]

After all the questions raised, I took a look at pgp.com's PGP Command Line
product information on their web site, as well as the GPG docs and program
itself in an effort to nail down an answer to whether they'd work together.

What I found was (I feel) something akin to burying it in the fine print.

Standards
=========
Their product supports OpenPGP.  So does GPG.

Encryption algorithms 
=====================
Their product -supports- IDEA.  You -can- modify GPG to use IDEA, although
the legality of doing so is questionable depending on circumstances,
locale, and licensing, as it's patented until 2007 (assuming no extensions
are sought and granted).  It's better just to avoid IDEA entirely inside
the US and countries that recognise US Patents, which isn't hard.

However, they also support Cast5, 3DES, TWOFISH, (all supported by GPG) and
AES (the AES is supported up to 256bit, and GPG supports AES, AES192, and
AES256 so it's a match).

Hashing algorithms
==================
Their product supports SHA-1, SHA-256, SHA-512, MD5, and RIPEMD-160.  GPG
supports SHA-1, MD5, RIPEMD-160, SHA-256, SHA-384, and SHA-521.

Compression algorithms
======================
Both their product and GPG support ZIP, BZIP2, and ZLIB.


On the surface, this all sounds like they're a near perfect match if you
avoid using IDEA, right?  It goes downhill sharply from here:

Key algorithms
==============
Their product supports Diffie-Hoffman, RSA, and DSA keys up to 4096-bits.
DSA and ElGamal is not listed.

GPG supports both DSA-only (1024-bit only) and RSA-only (up to 4096-bit),
but ONLY for signing, NOT for encryption, according to what you're told
when you generate the keys.  The default is a DSA and ELGamal combined key
that can be used for both encryption and signing.  Diffie-Hoffman is not
listed at all.  Please see what you're presented with in GPG:

Please select what kind of key you want:
   (1) DSA and Elgamal (default)
   (2) DSA (sign only)
   (5) RSA (sign only)
Your selection?

Given this, the main problem may be keys.  The assumption here, based
on their documentation, is that while pgp.com can handle pure DSA keys on
either end, but GPG reserves pure DSA keys for signing only and you may not
encrypt with them in GPG, the commercial product doesn't appear to support
DSA/ELGamal combo keys.  I'd verify this with the vendor before making a
move.

This could be problematic in the extreme.  If that's actually the case, I
-can- readily see where they said you'd have little to no success between
the two for encryption.  Signing, sure.  Not encryption--the biggest reason
to use it.

In addition, their highly-touted ADK (Additional Decryption Key) technology
(patented, no less!) is a JOKE.  The theory is that you encrypt with an
additional key so that if an encrypted document is encrypted with an
employee's key and expires, is cancelled, or is lost (or the employee
refuses to give up the passphrase), the data can be retrieved with an
additional key.  NEWS FLASH:  Been doing this since PGP 2.6 by simply
adding an additional recipient that is identical to the signing party.
What a bloody joke.

On the assumption that the documentation for both products is complete, I
think keys may indeed be an issue, and this probably will not fly for
encryption.  The "little" bit of "little to no success" may be signing and
verification of signing only from the GPG end.  The "no" part is probably
that you can't encrypt for pgp.com's solution with GPG due to a key
compatibility issue.

My advice is to ask pgp.com directly whether they support DSA and ELGamal
combo keys.  If they do not, you are going to -have- to go with the
commercial product if you want to encrypt between the two, as far as I can
see.

Best guess:  The docs are accurate and pgp.com went out of their way to
make it non-interoperable with GPG to force more revenue.  Wouldn't be the
first time a company did something like this, by a long shot.  Their
consistent reliance on the phrase "the most important 'x' algorithms" in
every section, including keys, leads me to believe they don't want people
to think GPG is important, which is a load of rot.

I hope this helps.  It indicates that, -if- the keys were compatible, all
the hashing, compression, and cipher algorithms are mutual, excepting IDEA.
However, it also indicates that they probably made keys incompatible.

Check with the vendor and NAIL them down to an answer of whether or not DSA
and ELGamal keys from GPG are supported.  If not, you're basically left
with no alternatives except getting everyone on GPG or getting everyone on
commercial.  And if you run into someone that has the flip side of what
you implemented, you'll either have to get them to switch or implement the
second package.

To be clear, it's not whether they support only ELGamal.  It's a DSA key
with an ELGamal subkey, actually.  And that's what I believe they're not
saying they support at pgp.com.

Condolences,

mark->
-- 
Fairlight->   ||| "I'm talking for free, it's a New  | Fairlight Consulting
  __/\__      ||| Religion..." --Le Bon              |
 <__<>__>     |||                                    | http://www.fairlite.com
    \/        |||                                    | info at fairlite.com