“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 same information, and are at least in theory totally interchangeable:

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

The only exception are cleartext signed messages, which have no binary format. The whole point of the cleartext signed format is to present 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 two or three things:

Header and footer lines, to mark the beginning and end of a block of OpenPGP data (in this case, -----BEGIN PGP PUBLIC KEY BLOCK----- and -----END PGP PUBLIC KEY BLOCK-----)
A base64 encoded block of 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 (it doesn’t add much value, is relatively expensive to compute, and it’s unclear what should happen 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 as rsop’s ASCII armored encoding (see above):

$ 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 differences aren’t particularly exciting. The checksum may be omitted for modern implementations, and the header/footer lines could easily be added manually.

So effectively, OpenPGP ASCII armor is just a slightly fancy variation of the general purpose base64 tool.