1

So I've never used gpg (2.0.14) before this week and I'm no cryptography pro, but the results I've been getting with gpg seem odd.

When I import keys (e.g. gpg --import public.key) that were generated by OpenPGP, gpg seems to process them successfully and reports no errors. However, when I then export those keys and compare with the originals, they are not the same. I assume this is why gpg fails to decrypt messages created [elsewhere] with the original public key.

Steps to reproduce: use a tool like https://sela.io/pgp/ to generate a key set, import into gpg, export from gpg, compare.

Incompatibility? Missed a step? Software gods continuing to plot against me with a series of minor nuisances?

1

The only differences I see is that GPG 2.0.14 (which I have on CentOS 6) outputs the key packets with old-format headers (presumably for wider compatibility, at least in years past) rather than new-format headers as used by that site (see rfc4880 section 4.2), and by default unarmored (but that's easily removed). The bodies of the packets, and thus the values of the keys, are identical as they should be.

However, importing only the public key never allows you to decrypt, or sign. The entire point of public-key or 'asymmetric' cryptography is that only the supposedly-unique holder of the private key, which GPG for historical reasons calls secret key, can decrypt or sign, whereas the public key can be public and used by anyone and everyone to encrypt or verify.

Added: although it's extremely dubious practice to use a website to generate your key(s), especially when it doesn't even say (that I can find) that the generation is in the browser (although based on CPU usage indicated by ProcExp that appears likely). And it's bizarre for them to generate a masterkey with flags CSEA and two subkeys both with flags SEA which are basically useless and a waste of CPU.

  • I'm thinking it's an interoperability problem. GPG, at least this version, does not seem compatible with OpenPGP. crypto.stackexchange.com/questions/13111/… – EricZ Jun 1 '18 at 23:00
  • @EricZ: that Q is about incompatibilities in the data (symmetric) cipher, or extreme size of asymmetric, neither of which applies here, and between GPG and commercial PGP not OpenPGP which is the standard not an implementation. But the keys on that site are interoperable with GPG 2.0.14: I generated a keypair and used the public key in BouncyCastle to encrypt (AES-256) and the private key in GPG 2.0.14 to decrypt with no trouble. – dave_thompson_085 Jun 2 '18 at 11:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.