.ASC File Format – ASCII armour

OpenPGP key

An .asc file is OpenPGP data in ASCII armour: binary packets in base64 between labelled lines, so they survive e-mail and copying as text. OpenPGP is defined by RFC 9580 (2024), which replaced RFC 4880; the IANA OpenPGP registries hold the code values. This page follows RFC 9580 section 6 (base64 conversions and ASCII armor) and section 7 (cleartext signature framework).

Layout

-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: Alice's key

mDMEZVPxABYJKwYBBAHaRw8BAQdA…
…
=(four base64 characters of CRC-24, optional)
-----END PGP PUBLIC KEY BLOCK-----
An armoured public key.
  1. A header line: five hyphens, BEGIN PGP, the kind of data, five hyphens. It must start a line and have nothing but whitespace after it.
  2. Armour headers, Key: value (a colon and one space), one per line.
  3. A blank line (empty, or only whitespace).
  4. The base64 data (RFC 4648 section 4), in lines of at most 76 characters. Readers ignore all whitespace in it.
  5. Optionally, the checksum on the next line: = and four base64 characters (discouraged, see below).
  6. The tail line: the same as the header line with END for BEGIN.

Header lines

LineContents
BEGIN PGP MESSAGESigned, encrypted or compressed files.
BEGIN PGP PUBLIC KEY BLOCKPublic keys (the usual .asc key file).
BEGIN PGP PRIVATE KEY BLOCKPrivate keys.
BEGIN PGP SIGNATUREDetached signatures, OpenPGP/MIME signatures, and cleartext signatures.

These four make up the IANA OpenPGP Armor Header Lines registry (RFC 9580 Table 16). A cleartext signed message starts with BEGIN PGP SIGNED MESSAGE instead (section 7.1).

Armour header keys

KeyMeaning
VersionThe implementation and version that wrote it. To minimise metadata it should not be written except for debugging with the user’s consent.
CommentA user-defined comment, any UTF-8 string (characters outside ASCII may not survive transport).
HashDeprecated. In cleartext signed messages: a comma-separated list of hash algorithm names (see below).
CharsetThe character set of the plaintext, overriding the UTF-8 default; readers may ignore it.

Unknown keys should be silently ignored. Armour headers have no length limit, but a key may be repeated with different values to keep lines short (section 6.2.2). They are not covered by any signature on the message.

Checksum

The optional checksum line is a CRC-24 of the binary data (before base64), written as = and four base64 characters. RFC 9580 section 6.1 gives the generator as 0x864CFB and the initial value as 0xB704CE, with this C:

crc = 0xB704CE;
for each octet:
    crc ^= octet << 16;
    repeat 8 times:
        crc <<= 1;
        if (crc & 0x1000000) { crc &= 0xFFFFFF; crc ^= 0x864CFB; }
result = crc & 0xFFFFFF;

A reader must not reject data because the checksum is present, missing, malformed or wrong. Writers should not generate it unless a consumer needs it, and must not for a message ending in a v2 SEIPD packet, for signatures that are all version 6, or for version 6 keys and keyrings of only version 6 keys.

Cleartext signed messages

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The signed text, with lines starting "-" escaped as "- -".
-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQ…
-----END PGP SIGNATURE-----

The text stays readable (section 7). Between the first line and the empty line the only header allowed is a well-formed Hash, which verifiers ignore; any other header there must make verification fail. Every line starting with - is dash-escaped by putting - in front (lines starting From should be too); the digest is computed over the unescaped text. Like any text signature (type 0x01, section 5.2.1.2), it is computed with CR LF line endings, with trailing spaces and tabs removed from every line, and without the line ending before -----BEGIN PGP SIGNATURE-----. RFC 9580 advises against the framework for text whose whitespace matters, such as diffs.