A detached signature block

Keys and signatures

A signature stored on its own, with the thing it signs kept somewhere else entirely.

The shape

Two markers with base64 between them, and no readable content at any point. It is the plainest member of the family to describe and the least self sufficient, because on its own it refers to a document you cannot see from inside it.

Opening marker

-----BEGIN PGP SIGNATURE-----

Contents

base64 only; no words, no message, nothing readable

Size

short by the standards of this family, commonly under a dozen body lines

Closing marker

-----END PGP SIGNATURE-----

Armoured ending

.asc, a text file with the markers above

Raw ending

.sig, usually bytes with no markers and no readable structure

Naming

the signed file name with the ending added, so the stem is shared

-----BEGIN PGP SIGNATURE-----

[body: 9 lines of base64 characters, removed here]
=xxxx
-----END PGP SIGNATURE-----

example-file.txt          the file itself
example-file.txt.asc      signature as armoured text
example-file.txt.sig      signature as raw bytes, no markers

The two endings are conventions rather than rules, and they are not always used consistently. What matters is the consequence: an .asc file opens in a text editor and shows the markers above, while a .sig file opens and shows meaningless characters, because it was never encoded as text in the first place. A .sig that looks like nonsense is behaving correctly.

Size is part of the shape here in a way it is not elsewhere. A signature is a small object, so the armoured form of one is a small block, and a file of half a megabyte carrying a signature marker at the top is announcing that something other than a signature is in it.

The stem that ties the pair together

Everything about the usefulness of this block depends on knowing which document it covers, and the block does not know. It carries no readable name, no path, no title and no description. What supplies that information is the filename, and specifically the stem: the part before the ending that was added.

So the pairing is held together by a convention about naming, and naming is the softest thing in any file system. A file can be renamed by anybody who can reach it, at any time, without altering a byte of its contents. Two files can be given a shared stem in a second. A file can also lose its ending entirely when it passes through something that rewrites names, at which point the pair silently stops looking like a pair.

A directory listing makes this vivid, because the pair appears as two adjacent lines that differ only at the right hand end. The lines look like evidence of a relationship, and what they actually show is alphabetical ordering. Reading such a listing has its own entry at a line from an archive listing.

How to check it by eye

What a wrong shape means

A file with the right ending and the wrong contents is the usual finding. Somebody saved a key block under a name ending .asc, because that ending is used for both. Somebody saved an armoured signature under .sig, or the reverse. Somebody pasted the signature and the message into one file, which turns the result into neither shape properly.

None of that requires an explanation involving bad intent. Files are saved by hand, names are typed by hand, and both are easy to get wrong when several similar looking blocks are open at once. The shape mismatch tells you the file is not what its name announces. It says nothing about why.

The one genuinely uninformative case is a detached signature with no file anywhere near it. There is nothing wrong with its shape. It simply has no counterpart, and a signature with no counterpart is an object with no function.

There is also a fault that is invisible by eye and worth naming for that reason. An .asc file can pick up an extra blank line at the end, or lose the final line break, when it travels through a system that normalises text files. The markers still read correctly, the body still forms a column, and nothing in the layout announces the change. Shape reading has a floor, and this is where it sits.

What a correct shape does not prove

Detachment is the whole difficulty. Everything that would make this block meaningful lives outside it.

• Which file it covers. The block contains no readable reference to any file, so the connection is carried entirely by the name someone gave it.
• That the file sitting beside it is the right one. Two files can share a stem because somebody renamed one of them.
• That the pair was produced at the same moment, or by the same person, or in the same place.
• That the file has not changed since. A file edited afterwards keeps its name and keeps its neighbour.
• Anything at all about the contents of the file, which this block does not describe and this site does not open.

A correct detached signature is a well formed object waiting on information it does not contain.

What this card is not

The form where the message and the signature share one document is at a clear signed message. A different way of pinning a file to a short string is at a file hash, and the general trap of trusting a name is at a filename.