-----BEGIN PGP SIGNED MESSAGE-----
hereafter the results of tests conducted between Hans Trygve Jensen
<hansino@...> and myself, as well as some findings resulting from
correspondence with Serge Cohen <cohen@...>.
I do not seek to draw any conclusions from these results, but rather
submit them to the macgpg team, for information and consideration.
Serge Cohen <cohen@...> will deal, in separate
communications, with some technical aspects deriving from the use of
different algorithms by GnuPG and PGP.
I do not mean to make comparisons between, or qualifications of the
characteristics of GnuPG and PGP. I only hope everything that can be
done will be done to smooth some apparent incompatibilities between both.
1. GPG DropThing (GPGDT)
1.1 It is already known to this forum, but it doesn't harm to repeat it,
that GPGDT will not allow to select for encryption, public keys which
have not a sufficient level of trust. If the user doesn't sign a key
(non exportable signature is recommended, lacking proper mutual
authentication, that key will not be eligible for encryption.
Nevertheless, GPGDT may display public keys, imported from PGPkeys (for
an instance) when, in PGP, those keys had a level of trust which is
considered "sufficient" by GnuPG. I cannot explain the hows and whys,
but that is, apparently, the way it is.
1.2 Although GPGDT doesn't allow, presently, to select more than one
public key to encrypt to (if you need to encrypt to multiple recipients,
for an instance)
But it will encrypt to the selected public key *and* to the sender's
default public key, provided GnuPG's options are set accordingly.
How do set GnuPG can be found by typing, in the Terminal, after the
- ---% man gpg This will print, in the Terminal the GnuPG manual page.
- ---% open -e ~/.gnupg/options This will invoke TextEdit, and will show
the GnuPG Options page.
1.3 If GPGDT doesn't let you sign or encrypt (it won't show the
"Retrieving Keys" rotating "candybar", or will display a warning
"Invalid Cipher Algorithm" when you want to sign a message in GPGDT's
window) it means that some options are activated in GnuPG's options,
that shouldn't be, or vice-versa.
For an instance, I tried to make GnuPG accept the option cipher-algo
CAST, hoping that this would improve GnuPG's compatibility with PGP. It
didn't, because CAST5 is the correct name of the algorithm, and anyway,
this option is activated by default in the current release of GnuPG. I
couldn't sign, but everything went back to normal after I inactivated
the CAST option.
This issue is not GPGDT's proper. It has to do with the contents of
GnuPG's options page, which are activated, which are not (the sign
pound # at the beginning of the line, before the name of the option,
will invalidate it).
2. The "bad session key" issue.
Messages encrypted in GPGMail, using a GnuPG generated key, when
received by a recipient who is using, for an instance, PGPKeys under OS
9.x (specifically, version 6.5.8), and probably also under
Windows/something, will give an error message, to the effect that the
"session key is bad".
This has to do with the algorithm or algorithms used by GnuPG, and the
ones accepted by PGPKeys.
Serge Cohen will explain this issue, in a separate post.
3. The "bad signature" issue.
Messages signed in GPGMail, using a GnuPG generated key, when received
by a recipient who is using PGPKeys 6.5.8 (Mac) will produce, upon
verification, a "bad signature", invariably.
However, if the signer/sender of the message inactivates, in GnuPG's
options, the option force-v3-sigs , messages signed afterwards will be
correctly verified in PGPKeys.
4. The IDEA issue.
Although GnuPG accepts the RSA standard, it doesn't incorporate the IDEA
algorithm (which is under license). Therefore, RSA keys generated in
PGPKeys (always with the IDEA cipher) will not be accepted by GnuPG. If
you try to decrypt a message that has been encrypted with such a key,
you will get an error message.
I know that the mac-gpg team intends, or intended, to solve this
problem, the end result possibly being a new release of GnuPG where IDEA
would be incorporated. We shall have to wait and see what comes out of
Another example of the "rejection", by GnuPG, of RSA keys with IDEA.
I had extracted the keyblock of one of my RSA/IDEA public keys, in order
to send it to somebody (the "why" and "what for" are not important right
After I got it on the Terminal, I copy/pasted in into GPGDT, in order to
send it, and automatically, I hit the Encrypt command, and then the Send
logo. I got a warning refusing to encrypt.
5. Keys generated in GnuPG
5.1 Public keys generated in GnuPG, when exported/imported into PGPKeys
(version 6.5.8, I don't know if further versions of PGPKeys behave
differently), will show, in the Properties, that it is a DH/DSS key (in
GnuPG it was a DSA Elgamal key), but in the Cipher field, it will show a
This implies, apparently, that the algorithm used by GnuPG is not
accepted by PGPKeys.
This point will be covered under the algorithms issue, in Serge Cohen's
5.2 Exporting/Importing GnuPG keys to PGPKeys, and vice-versa
When I started learning about GnuPG a few months ago, I had already been
working with PGPKeys (Mac) since 1994 approximately, collecting some
5.2.1 I learned that in order to export keys generated in PGPKeys, and
import them into the GnuPG keyring, I had to be careful about two points:
- - when exporting keys from PGPKeys, *not* to include the PGP 6.x
- - to change the exported file, from Mac line ends, to Unix line ends,
using a suitable text editor, e.g. BBEdit. Which I did, and it worked,
both for public and for private keys.
5.2.2 The reverse process was not the same:
- - exported *public* keys, generated in GnuPG, and converted from Unix to
Mac line ends, were accepted by PGP keys.
- - exported *private* keys were not. PGPKeys reacted with an error
message, like "No keys found in file".
I found another way to do it, both for public and private keys generated
- - in the Terminal, export/print an armor file of the required key block.
e.g. for a public key: after the prompt % gpg --armor --export [key ID]
for a private key: after the prompt % gpg --armor
- --export-secret-key [key ID]. For this, you may have to add the option
- - Copy the keyblock from the Terminal, and paste it into a message
window in Eudora version X
- - send the message to myself, receive and open it in Eudora Classic (in
a different computer where I run 9.1 for my convenience),
- - in Eudora Classic (in that different computer) hit the ADD Keys
under Edit>Message Plug-ins>PGP Add keys.
The key, whether public or private, was accepted by, and integrated in
where I could have a regular "key pair". But as I already pointed out,
the properties of such a key show a blank field in "Cipher".
I hope I haven't forgotten anything relevant, and I apologize for the
length of this message, which may contain information already known to
many of the forum members.
And a nice week-end
PS - My GnuPG keys are now on the servers.
Charly Avital <shavital@...>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----