“ASCII Armor” #

One of the properties of OpenPGP that is recognizable to many is its “armored” format.

For example, certificates (aka public keys) are often seen in armored form like this:

ASCII armored vs. binary #

Almost all OpenPGP data can be represented in two formats, which contain the exact information, and are as such at least in theory totally interchangeable:

“Raw” binary representation,
The ASCII-armored representation of the same data.

The one exception are cleartext signed messages, which have no binary format. The whole point of that format is to keep the message content in human-readable form. The signature part of a cleartext signed message is always armored, so that it can be handled in environments such as an email application.

Transforming keys and messages between the two shapes #

SOP implementations can handle binary and ASCII armored representation interchangeably. Many use armored output formats by default.

Additionally, SOP specifies a pair of commands armor and dearmor to add and remove armor.

For example, we can transform the alice.cert from the hello world article from its armored format to binary, like this:

cat alice.cert | rsop dearmor > alice.pub.pgp

The resulting binary representation in alice.pub.pgp uses a little less disk space:

$ ls -l alice.cert alice.pub.pgp
-rw-r--r--. 1 heiko heiko 616 Apr 24 18:10 alice.cert
-rw-r--r--. 1 heiko heiko 394 Apr 24 20:28 alice.pub.pgp

However, these two representations of Alice’s certificate are entirely interchangeable, for the purpose of using them with SOP (and also when using them with most other PGP software).

ASCII armor under the hood #

OpenPGP ASCII armor is a combination of three things:

Header and footer lines, to mark the beginning and end of a block of OpenPGPPGP data (in this case, -----BEGIN PGP PUBLIC KEY BLOCK----- and -----END PGP PUBLIC KEY BLOCK-----)
A regular base64 encoded section of the data
Historically, a CRC24 checksum of the data block (in this example, the fragment =4FiZ) - though for new OpenPGP data, adding this checksum is discouraged, since it doesn’t add much use, is relatively expensive to compute, and it’s unclear what should follow if the checksum isn’t correct

Example #

Just to get a feel for things, we can see that encoding the binary file alice.pub.pgp with the regular base64 commandline tool yields the same data:

$ cat alice.pub.pgp | base64
xjMEaApiDxYJKwYBBAHaRw8BAQdALKjyvqcoQ37MMHV5cIyEZjSK/XxnIAa/L/3cixX5hkvNBWFs
aWNlwpgEEBYIAEAFAmgKYg8WIQTQbolGjae+MmwHtzdpyBjxHjuHYwIbAwIeAQQLCQgHBBUKCQgB
[..]

The regular base64 tool doesn’t produce the checksum at the end, and it doesn’t produce the header and footer lines.

But those aren’t particularly exciting. The checksum may be omitted, and the header/footer lines could easily be added manually.

So effectively, OpenPGP ascii armor is just a slightly fancy variant of that the general purpose base64 tool does.