Tag Archives: Complexity

Signing and verifying files using GnuPG

I’m convinced almost nobody actually uses this functionality of GnuPG, because it is somewhat awkward and confusing for myself, having been a student of the OpenPGP protocol for many years. I thought this would make a good post to explain what to do with those PGP signature files you often see alongside the download links of free/open source software.

The vast majority of signatures use the RSA algorithm. GnuPGP/commercial PGP give you two choices, and they are both probably fine, but it makes the whole thing more confusing. The RSA algorithm can be used for encrypting and signing whereas the alternative ElGamal algorithm uses the official sounding DSA, Digital Signature Algorithm. I don’t even bother implementing ElGamal due to the amount of time it would take to implement and the nonexistent payoff. Since RSA is the de facto standard for even mainstream cryptography, combined with the fact that it can be used for both signing and encryption, I never though it worth my while to develop, debug, test, and all that comes with this labor of love (of the Fourth Amendment).

Ironically, for GnuPG 1.4.20, which is the easiest open source PGP distribution to build, the signing key is already expired. This is only a problem if somehow the private RSA key came into the possession of a malicious part. Before you do anything, you must import the signing certificates from the offical GnuPG website.

Importing GnuPG all release signing into our self compiled GnuPG 1.4.20

If there’s not enough evidence to support the waste of time that is implementing testing, regression testing, and supporting DSA, even the official GnuPG releases are signed with RSA.

Verifying a file using GnuPG and an attached signature is a simple command line argument that should only take a few tries to get right.

About as good of a verification as we are going to get that the gnupg-1.4.20.tar.bz2 hasn’t been tampered with…

Again, this is the problem I see with GnuPG… we’re getting conflicting messages. First the good news: it appears that two parties have signed the tar ball with their private keys so unless both of those keys have been compromised the by malicious entities, the tar ball is intact. The first warning is that “there is no indication the signature belongs to the owner”. So apparently, importing the keys from GnuPG’s very own website 10 minutes ago which is secured by SSL/TLS is not enough assurance the key is valid. I wonder why they even bother to post them. The other is that the key is expired…

This would make sense since 1.4.20 is quite an old release, I’m just using that version since the compilation is so much more straightforward. Newer versions of GnuPG have a modularized codebase but the actual encryption code is line for line the same as 1.4.20 — and obviously showing it’s age since it’s based on streams which made a lot more sense in 1999 when memory was much more limited on the average enthusiast computer. Streaming is more memory efficient at the cost of code complexity. (i.e. bugs)

Thus a new Privacy Guard is needed. And open source is not a panacea, perhaps including a sane file verification function in the (long overdue) next update of NouveauPG.