Another day another attack against GnuPGP tools. I have long believed that the complicated integration mechanism that GPGTools use to integrate with the Mail client are vulnerable to attack. Not too long ago Internet Explorer browser extensions were the attack vector into Windows PC’s.
Remember with NouveauPG, the entire app is sandboxed. The only way to get data in or out is by selecting a file using the system file dialog box, or using the clipboard. No internet access, third party plug-ins or anything. The only reason encryption is not ubiquitous by now is the trade-off between usability. More ‘convenient’ schemes always seem to backfire. NouveauPG is as simple as I know how to make it.
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.
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.
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.
Compiling from source code is a straightforward way to ensure that you have a genuine copy of GnuPG on your machine. Since GnuPG may be used to verify other software packages, it is important that your copy is not tampered with.
This post will outline the steps for compiling GnuPG classic v1.4.20 from source for Mac OS X rather than the latest version of GnuPG (v2.0.x) because it is much simpler to compile. Compiling GnuPG from source is certainly not any more difficult that using GnuPG, which is a command line program.
1.) Install command line developer tools for Mac OS X. This is dead simple on recent versions of Mac OS X 10.9 and up, simply open the Terminal and type “xcode-select –install”. The dialog below will appear and allow you to install the command line tools.
I finally have the Bitcoin activation system up and running. Now if you want to purchase NouveauPG, you don’t need to go through the Mac App Store. The first time NouveauPG is run on a Mac, it generates a random UUID. When you provide a valid UUID to the activation page, you will be assigned a Bitcoin deposit address. When you deposit enough Bitcoin, a signature will be generated that can be copied and pasted into NouveauPG to unlock it. No network access is necessary.
A few years ago, I swore to myself that I would not publish apps that I didn’t use myself. NouveauPG for iOS has some issues I don’t have the time to fix in the near future. I hope to have it back and better than ever in 2016, but I will not publish it until it is in good enough shape that I have it on my phone.
I use NouveauPG for OS X on a regular basis, so I want to concentrate on that for the time being.
The leading OpenPGP client for Mac OS X has recently pushed a security update due to a bug that allows a local user to execute shell commands with root privileges.
As if it weren’t enough, by default, GPG Suite regularly contacts gpgtools.org to check for updates. So not only does gpgtools.org keep tabs on the IP addresses you use without explicitly getting permission, a carrier or state level entity could easily compile a list of GPG Suite users by monitoring requests to the gpgtools.org upgrade server (here and here). It doesn’t matter they are using SSL/TLS because the private information is your IP address.
Think about it, after a few months, your upstream carrier (or whomever has access to their logs) could compile a list of every IP users of GPG Suite use. My opinion of GPG Suite users notwithstanding, I am sure they have more interesting data stored on their computers than the average person.
NouveauPG is sandboxed, so it is entitled only to access files selected by the user using the system open and save dialog box. Absolutely no network access allowed. (The only autoupdate mechanism is through the App Store version, which is the same one used for OS X autoupdate. There is no way for a third-party other than Apple to know exactly what is being updated, and tracking IP’s to the Apple update servers will only give you a list of Macintosh users.)
To encrypt a message for some party, you must first import their certificate into NouveauPG.
Before using a certificate, be sure it’s valid. NouveauPG will warn before performing encryption with an invalid certificate.
Click on Compose Message to write a new message for the recipient.
You can either type a message or choose a file to encrypt. At this time, NouveauPG will only encrypt plain text files. (UTF-8 supported)
You can export your encrypted message by copying to the clipboard, or save as a text file.
If you wish to receive encrypted messages from another party, you must first create a new identity. Press the add button on the lower left hand corner of the window.
An identity looks a lot like the public key certificate but you have two more options: Decrypt Message and Private Keystore
The two new options are protected by the password you chose while creating the account.
To decrypt a message, either paste the encrypted message in the space provided or load an encrypted message from a file.
You should use the Private Keystore feature to backup your identity. Make sure your keystore is saved on an encrypted volume. To restore an identity, or move it to a new computer, simply import the private key block.