KEY File Documentation

Summary

A .key file in this sense is a licence or encrypted security file: either a software activation/registration file that a specific program reads to unlock itself, or a cryptographic key such as a TLS or SSH private key. It is application-defined, so there is no single format. A PEM-encoded key is readable text beginning -----BEGIN PRIVATE KEY-----; a licence .key is whatever layout its vendor chose. Private keys are secret material and must never be shared.

Technical details

FeatureValue
Full nameLicence or encrypted security file
File extension.key
Format typeApplication-defined; no single fixed structure
CategorySecurity / licensing files
Common meaning 1Software licence / activation file read by its owning program
Common meaning 2Cryptographic private (or public) key, often PEM-encoded
Typical PEM MIME typeapplication/x-pem-file
PEM encodingBase64 of DER, wrapped in -----BEGIN…----- lines
Key standards (crypto case)PKCS#1 (RFC 8017), PKCS#8 (RFC 5208), X.509 SubjectPublicKeyInfo
PEM text marker (RFC 7468)2D 2D 2D 2D 2D = ASCII ----- at offset 0
Binary variantsDER (binary ASN.1), or a vendor’s own licence layout
Created byThe licensed application, or a crypto tool (OpenSSL, ssh-keygen)
Opened by userUsually not; the owning program reads it
Contains executable codeNo
SensitivityHigh for private keys and paid licences; keep secret
Related extensions.pem, .crt, .cer, .pfx, .lic, .der
Structure at a glance

A .key has no single format. When it is a PEM cryptographic key it is readable ASCII that opens with five dashes and a label, for example -----BEGIN PRIVATE KEY----- (hex 2D 2D 2D 2D 2D 42 45 47 49 4E), followed by Base64 and a matching -----END…----- line. When it is a binary DER key or a vendor licence file it has no reliable magic number, and only the owning application knows how to read it. Inspect the first bytes: printable -----BEGIN means PEM; anything else is application-defined.

What is a .key file?

Under this meaning, a .key file is a licence or encrypted security file: a small file that authorises or secures something, rather than a document you edit. The extension is generic. It is not one format; it is a label that different programs attach to two broad kinds of file. The first is a software licence or activation file that a specific application reads to confirm it is registered. The second is a cryptographic key, such as a TLS server key or an SSH private key, used to prove identity or to encrypt and decrypt data. Because the layout is chosen by whatever tool wrote the file, there is no universal internal structure and, for the binary variants, no reliable magic number.

The one thing these files share is that they are secrets or entitlements. A paid licence .key unlocks a product; a private .key can decrypt traffic or impersonate a server. That is why the safe default with any .key is to leave it where its owning program expects it and never post it publicly.

Software licence and activation .key files

Many applications, historically antivirus suites and virtualisation tools among them, store their registration in a .key file that the program loads at startup. The contents are entirely vendor-specific: some hold a signed blob binding a serial number to an expiry date and a feature set, others hold an encrypted token, and older ones held little more than a product code and a checksum. A user rarely opens such a file directly; the workflow is to drop it into the application’s licence folder, or point the program’s “import licence” dialog at it, after which the app validates it. Because the format is private, a licence .key for one product is meaningless to another, and there is no generic viewer that can interpret it. If you open one in a text editor you may see a header and Base64, or you may see raw binary, depending on the vendor.

PEM cryptographic keys: the -----BEGIN structure

The other common .key is a cryptographic key in PEM form. PEM (defined for textual keys and certificates in RFC 7468) is a text wrapper: the binary key is DER-encoded, Base64-encoded, and bracketed by label lines. The label tells you exactly what the file holds:

-----BEGIN PRIVATE KEY-----          PKCS#8, any algorithm
-----BEGIN RSA PRIVATE KEY-----      PKCS#1, RSA only (legacy)
-----BEGIN EC PRIVATE KEY-----       SEC1 elliptic-curve private key
-----BEGIN ENCRYPTED PRIVATE KEY-----  PKCS#8 wrapped under a passphrase
-----BEGIN PUBLIC KEY-----           X.509 SubjectPublicKeyInfo
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQ...   (Base64 body)
-----END PRIVATE KEY-----

Between the markers, the Base64 body decodes to a DER byte stream, which is the ASN.1 encoding of the key. A PKCS#8 private key (RFC 5208) begins with a version integer, an AlgorithmIdentifier naming the algorithm by OID (for example 1.2.840.113549.1.1.1 for RSA), and an octet string carrying the algorithm-specific key material. A legacy RSA PRIVATE KEY uses the PKCS#1 layout (RFC 8017): a sequence of the modulus, public exponent, private exponent and the CRT parameters. The same key can also be stored as raw binary DER with the same .key extension, in which case there are no dashes and the file starts with the DER SEQUENCE tag 0x30.

Encrypted keys and passphrases

A private key .key is frequently encrypted at rest so that possessing the file is not enough to use it. In modern PKCS#8, an ENCRYPTED PRIVATE KEY stores the key material under a key-derivation-plus-cipher scheme (PBKDF2 deriving an AES key from a passphrase, for example), and the DER records the KDF and cipher parameters so a tool can reconstruct the decryption. Older OpenSSL “traditional” keys instead put a header inside the PEM block, such as Proc-Type: 4,ENCRYPTED and DEK-Info: AES-256-CBC,<iv>, before the Base64. Either way, using the key requires the passphrase; without it the file is inert ciphertext. This is why a stolen encrypted key is less dangerous than a stolen plaintext one, and why the passphrase must be strong.

Telling a licence file from a key, and reading it safely

Because .key is application-defined, identification comes from the bytes and the context, not the extension. Open the file in a text viewer. If it begins with -----BEGIN it is a PEM cryptographic key or certificate, and the label after BEGIN tells you whether it is a private key (secret), a public key (shareable), or an encrypted private key. If it begins with the byte 0x30 and is otherwise unreadable, it is likely binary DER. If it is readable but has no PEM markers, it is probably a vendor licence blob that only its program understands. A safety note that is genuinely technical here: a private key or a paid licence file is a credential. Anyone who obtains a plaintext private .key can impersonate the server or user it belongs to and decrypt captured traffic, so these files carry restrictive filesystem permissions by convention (owner-read-only) and should never be committed to a repository, emailed, or uploaded to an online converter.

FAQ

What program opens a .key file?

It depends on which kind you have. A licence .key is read by the application it belongs to; you import it there rather than open it. A PEM cryptographic key is text you can inspect in any editor and use with tools like OpenSSL or ssh, but you rarely “open” it as a document.

Is it safe to share a .key file?

A public key or certificate is safe to share. A private key or a paid licence file is not: it is a secret that grants access or unlocks a product. Sharing a private .key lets others impersonate you or decrypt your data, so keep it confidential.

Why do some .key files look like text and others like binary?

The same key can be stored two ways. PEM wraps the key in Base64 with -----BEGIN…----- markers, so it is readable text. DER is the same key as raw binary ASN.1, starting with the byte 0x30. Vendor licence files use their own private layout, which may be either.

References