SIG File Documentation

Summary

A SIG (signature) file is most often an OpenPGP detached signature: a small companion file (for example installer.exe.sig) that lets you verify a download is genuine and unaltered. It is not a document to open — it is cryptographic data checked against the file it sits next to, using GnuPG or Gpg4win via gpg --verify file.sig file. A “Good signature” confirms integrity and authorship. Its MIME type is application/pgp-signature. The extension is also used for plain-text email signature blocks.

Technical details

FeatureValue
Full nameOpenPGP Detached Signature
File extension.sig
MIME typeapplication/pgp-signature
Format typeCryptographic detached signature over a separate file
EncodingBinary OpenPGP packet, or ASCII-armored text
StandardOpenPGP — RFC 4880 (2007), updated by RFC 9580 (2024)
LineagePGP (1991), RFC 2440 (1998)
DeveloperPGP / GnuPG; IETF OpenPGP working group
Open standardYes
ASCII armor header-----BEGIN PGP SIGNATURE-----
Binary first byteSignature packet tag (high bit set, e.g. 0x88, 0x89, 0xC2)
SignsA hash of a separate file (the signature holds no copy of it)
Verify commandgpg --verify file.sig file
Key material neededThe signer’s public key (imported separately)
Contains executable codeNo
Text (armored) sibling.asc
Binary sibling.gpg
Related extensions.asc, .gpg, .pgp
Also used forPlain-text email signature block; legacy Broderbund Print Shop project
Specificationrfc-editor.org/rfc/rfc4880
Structure at a glance

A detached OpenPGP signature comes in two encodings of the same data. The ASCII-armored form is text: it begins -----BEGIN PGP SIGNATURE-----, wraps a Base64 payload, ends with a Base64 CRC-24 line prefixed = and a -----END PGP SIGNATURE----- footer. The binary form is a raw OpenPGP signature packet whose first byte is a packet tag with the high bit set (values such as 0x88, 0x89 or 0xC2). Either way the file is identified by sitting beside the file it signs — archive.tar.gz next to archive.tar.gz.sig — and is only meaningful when checked against it.

What is a SIG file?

A .sig file is, in its dominant and highest-value meaning, a detached OpenPGP signature. When a project publishes a download, it often publishes a tiny companion file alongside it — tor-browser.exe and tor-browser.exe.sig, or debian.iso and debian.iso.sig. That .sig is a cryptographic signature computed over the download. Checking it against the publisher’s public key proves two things at once: that the file is exactly what the publisher signed (integrity) and that it really came from them (authenticity). Linux ISOs, Tor Browser, VeraCrypt and GnuPG itself are all distributed this way.

OpenPGP signatures descend from PGP, released in 1991, and are specified in RFC 4880 (2007), updated by RFC 9580 in 2024. A detached signature is data about another file, not a container for it: there is nothing inside to render, and no “open” action that shows you a document. The file exists to be verified. The rest of this page explains what is actually in that signature and how the verification works. (Two unrelated uses of the extension exist — a plain-text email .signature block, and legacy Broderbund Print Shop project files — but neither is the download-verification signature described here.)

Detached signatures versus signed messages

OpenPGP can produce several things that all contain a signature, and the distinction matters. An inline or cleartext signature bundles the signed data and the signature together in one file. A detached signature keeps them apart: the signature is its own file and the signed data is left completely untouched. That is exactly what you want for a software download — the installer stays byte-for-byte identical and downloadable on its own, while a separate small .sig travels beside it. Nothing is added to or wrapped around the payload, so an unverified user can still use the file and a careful user can check it.

A detached signature never contains a copy of the data it signs. It contains a signature over the data’s hash. That is why a signature for a 4 GB ISO is only a few hundred bytes: the signing operation hashes the whole file, then signs the hash. It also means the .sig is bound to one exact file — change a single byte of the download and its hash no longer matches, so verification fails.

Inside the signature packet

The binary form of a .sig is a single OpenPGP signature packet. Every OpenPGP packet starts with a tag byte whose high bit is set; for a signature packet the tag identifies it as such (this is why the first byte of a binary detached signature is a value like 0x88, 0x89 or, in the newer packet format, 0xC2). The packet body carries the fields a verifier needs:

FieldWhat it holds
VersionSignature version (v4 under RFC 4880; v6 introduced by RFC 9580)
Signature typeWhat was signed (for a file, type 0x00 binary document)
Public-key algorithmRSA, or an elliptic-curve algorithm such as EdDSA / ECDSA
Hash algorithmThe digest used, e.g. SHA-256 or SHA-512
Hashed subpacketsMetadata covered by the signature: creation time, issuer key fingerprint
Unhashed subpacketsAdvisory metadata not covered, e.g. the issuer key ID
Left 16 bits of hashA quick check value on the computed digest
Signature valueThe MPI(s) of the actual public-key signature over the digest

The split between hashed and unhashed subpackets is a real security feature, not bookkeeping. Anything in the hashed area (notably the signature’s creation time and the signer’s key fingerprint) is itself part of what the signature covers, so it cannot be altered without breaking the signature. The unhashed area holds hints that speed up finding the right key but that a verifier must not trust on their own. To verify, the tool recomputes the document’s hash together with the hashed subpackets and checks that against the signature value using the signer’s public key.

ASCII armor: the same signature as text

Many publishers ship the armored form instead, sometimes named .asc but often still .sig. ASCII armor Base64-encodes the binary packet and wraps it so it survives email and web pages that would corrupt raw bytes:

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

iQEzBAABCAAdFiEE... (Base64 of the signature packet) ...b2Rq
=Fq7P
-----END PGP SIGNATURE-----

The block is pure text. The Base64 body is the identical signature packet described above; the final line beginning with = is a Base64-encoded CRC-24 checksum of the binary data, a fast corruption check on the armor itself. Because armored and binary signatures decode to the same packet, they verify a file the same way. You can convert between them with GnuPG (gpg --enarmor and gpg --dearmor), and the sibling extensions reflect the two forms: .asc is conventionally armored text, .gpg conventionally binary, but the bytes are OpenPGP either way.

The verification workflow, step by step

Verifying a download is a fixed sequence. First install the tools: GnuPG on macOS or Linux (often preinstalled on Linux), or Gpg4win on Windows, which bundles GnuPG with the Kleopatra GUI and a right-click GpgEX menu. Then:

1. Put the download and its .sig in the same folder.
2. Import the publisher's public key:
      gpg --import publisher-key.asc
3. Verify:
      gpg --verify installer.exe.sig installer.exe
4. Read the result:
      gpg: Good signature from "Publisher <...>"
      Primary key fingerprint: ABCD 1234 ...

Two arguments are given to --verify: the signature first, then the data file. GnuPG hashes the data, looks up the signer’s key by the issuer fingerprint in the signature, and checks the math. “Good signature” is necessary but not sufficient — you must also confirm the key fingerprint matches the one the publisher advertises on an independent, official channel. If you skip that, an attacker who replaced both the download and the key could still show “Good signature”. To sign your own file, the reverse is gpg --detach-sign file (add --armor for a text .asc), which produces file.sig that others verify with your public key.

What a signature does and does not prove

A detached .sig is harmless in itself — it contains no executable code, and its whole purpose is to protect you. But two limits are worth stating plainly. First, verification is only as trustworthy as the key: download the publisher’s public key from an independent official source and confirm its fingerprint, because a “Good signature” against an attacker-supplied key proves nothing. Second, a good signature proves integrity and authorship, not that the software is safe — a malicious publisher can sign malware perfectly well. Two common failures are easy to read: “no public key” means you have not imported the signer’s key yet, and “BAD signature” means the file does not match the signature (a corrupt or tampered download, or the wrong file paired with the .sig).

Frequently asked questions

Can I just open a SIG file to read it?

There is nothing readable to open. A detached signature is cryptographic data about another file, not a document. Its only use is to be checked against that file with gpg --verify file.sig file. Opening it in a text editor at most shows the ASCII-armor wrapper or raw bytes, which mean nothing on their own.

What is the difference between .sig and .asc?

They are the same OpenPGP signature in different encodings. A .sig is usually the binary signature packet; a .asc is that same packet ASCII-armored into text. Either verifies a file identically. Convert with gpg --enarmor or gpg --dearmor.

I got “BAD signature” — what does that mean?

The data file does not match the signature. Either the download is corrupt or was tampered with, or you paired the .sig with the wrong file. Re-download the file from the official source and verify again, making sure the signature belongs to that exact file.

References