Secrecy and (file) Corruption – diving into the murky world of GPG encryption

Transferring sensitive data between systems often requires some for of encryption to ensure that the data is protected from prying eyes.
One common method of achieving this is to use Gnu Privacy Guard (GPG).
What I’m going to look at here is :

• Creating GPG keys on a server
• Using a Public Key to encrypt data on a different machine
• Decrypting an encrypted message
• Things to try if you get some of the more wacky GPG error messages

If you’ve stumbled on this post because of the last of these, you’re in good company. I’m sure someone initimately familiar with this tool will instantly know the meaning of the error message “Ohhhh jeeee: mpi larger than packet” but as far I’m concerned, it may as well have read “Divide by Cucumber Error”.
Hopefully, things will become clearer down the page…

Creating a GPG key

In fact, we’ll be creating two keys. The Public Key is, as it’s name suggests, generally available and anyone wanting to send us a message need only use that key to encrypt it.
The Private key is the one that only we have access to and which we can use to decrypt files encrypted with the Public Key.

To create the keys, we need to be on the server that will receive these files.
Once there, we simply run :

which results in :

NOTE – according to the manual, the default settings are sufficient in most cases so accept them unless you have a specific reason to change them.
For the length of time the key is valid, enter “0” if you don’t want it to expire.
In this case, I’ve selected 7 days.
GPG should now prompt you for a passphrase.
NOTE – it’s really important that you remember the passphrase as otherwise you will not be able to decrypt any messages :

Finally, the keys will be generated :

Distributing the Public Key

Before we go any further, we probably want to obtain a text version of our public key that we can then distribute.
This can be accomplished by running :

We now have a file that contains our Public Key. It looks like this :

I can now distribute this to anyone who wants to send me an encrypted message.

Using a Public Key to encrypt data on a different machine

I’m now on a different machine onto which I’ve downloaded the public key.
I now need to import it :

…which returns…

I can get a list of available keys by running :

…which confirms that the key is now present in my keyring :

We have some data in a file called secret_message.txt that we want to send.
With the recipients public key imported, we can encrypt the file like this :

At this point GPG will prompt you to confirm that you want to do this :

We now have an encrypted copy of the file…

…which is encrypted :

Indeed, the .gpg version of the file contains this :

We can now transfer the encrypted file to the target server.

Decrypting the file

Once the file has reached it’s intended destination it can now be decrypted by the intended recipient using their private key.
Note that in order to do this, they need to know the passphrase used to create the key in the first place :

…where ************ is the passphrase.

Once we run this we can see that we have generated a log file, together with the output file :

If all has gone according to plan, the logfile should look something like :

Also, we should now be able to read the decrypted contents of the file :

When things go horribly wrong

In using GPG, I’ve found that error messages regarding packet sizes can be quite common when you first begin receiving file from a new source system. Perhaps the most cryptic of these is :

When this sort of thing crops up it appears to be the result of a file corruption. Either the key file used to encrypt the data, or the encrypted file itself, has somehow become corrupted.
There are at least two common ways for this to happen.

Transferring a text key from Windows to Linux

Remember that, in the example above, we used a text file to distribute our public key.
As you probably know, Windows uses two non-printing characters to terminate a line – Carriage Return (to move the cursor to the start of the line) and Line Feed (to move down to the next line). This means that each new line is preceeded by the ASCII characters 13 and 10.
Linux uses a single new-line character – ASCII 10 – in which the Carriage Return is implicit.
Unfortunately conversion between the two new-lines is not automatic. Therefore, if you find yourself transferring the text copy of a public key from a Windows system to a Linux system then you need to convert the new-lines to Linux using the dos2unix utility before using the key for GPG encryption.
In our example, we’d need to run :

Note : on the off-chance it’s not already installed, you can install this utility as follows :

On a RedHat-based system (RHEL, CentOS, Fedora etc) :

On a Debian-based system ( Debian, Ubuntu, Mint etc) :

One useful aspect of this utility is that it will not alter the file unless it finds new-lines that require changing.

Selecting the file transfer mode over sftp

Unless you are an aged person such as myself, who remembers the time when you’d ftp files on the command line, you probably won’t be aware that ftp ( the forerunner to sftp), had different modes for text files (ascii) and binary files (binary). However, many modern sftp client tools do remember this distinction. Take FileZilla, for example :

As we have seen, GPG encrypted files are binary. If they are transferred in ASCII mode then they will become corrupted and trigger GPG’s packet-size obsession when you try to decrypt them.

If you’re hitting this issue then make sure that your sftp client isn’t being “helpful” by automatically selecting the incorrect transfer mode for your encrypted file.

Using FileZilla as an example, you can specify the correct mode when you invoke a Manual Transfer from the Transfer menu :

Hopefully you should now be free of file corruption and be able to proceed without having to re-initialize your FTB.