Is the paper itself the encrypted archive?

Usually the term refers to key or recovery material, so check the specific design.

Does every paper key work in every product?

No. Formats and recovery relationships differ.

Can a public-key printout replace secret material?

No, not for recovering the corresponding private key by itself.

AI Glossary / Data governance and quality / Advanced

Paper key

Definition

A paper key is a physical, paper-based representation of cryptographic secret or recovery material. Its purpose is to preserve an alternative way to regain access when an ordinary digital copy or device becomes unavailable. Exactly what the paper contains, and what else recovery requires, depends on the system. Printing a public key alone does not create a usable backup of the corresponding private key.

What it means

The central distinction is between storing access material and storing the protected information itself. A page might help recover a key without containing the encrypted archive that key unlocks. Both can therefore matter during recovery.
The term also has product-specific meanings. David Shaw's Paperkey utility archives essential OpenPGP secret material for reconstruction with the corresponding public key. Keybase documentation describes paper keys as functioning like device keys for recovery. These mechanisms should not be treated as interchangeable simply because both involve paper.

How it works

In a general recovery design, software produces a printable representation of the relevant material. An authorized custodian retains it, and a later recovery process reads or transcribes it using the appropriate software and supporting information. Text, encoded symbols and other representations can have different handling requirements.
For the OpenPGP Paperkey utility specifically, existing protection of the secret key is preserved: it does not add encryption merely by printing the information. Reconstructing a passphrase-protected key does not remove the need for its passphrase. A useful description therefore identifies dependencies as well as the printed page. A page that looks intact is not evidence that the entire recovery path works.

Three practical examples

Archive recovery: A publisher keeps an encrypted archive and a recovery package. During a rehearsal, the team checks whether the package can restore access to a harmless test archive. The paper component is only one dependency; the encrypted file and compatible recovery process must also survive.
Staff handover: A departing administrator records where an approved recovery package is held and who may request access. The ordinary handover document contains references and responsibilities, not the secret material itself. This separates operational continuity from indiscriminate copying.
Documentation review: A writer sees a paper recovery feature in two products. Instead of assuming identical behavior, the writer asks what each printed item represents and whether it depends on a public key, another secret or an active account relationship. The resulting explanation avoids misleading readers about portability.

Think of it this way

Think of a carefully labeled spare part stored for a machine you may need to repair years later. Having the part is helpful, but you also need the correct machine, compatible tools and instructions. A part for a different model may look similar and still fail. The analogy explains recovery dependencies; it does not imply that secret key material should be displayed or handled like an ordinary mechanical component.

Worked example

Consider a fictional rehearsal based on an encrypted OpenPGP key backup. Call the printed secret material S, the matching public key P and the required passphrase W. These letters are labels, not real credentials or a cryptographic formula.
The team prepares four test cases. Case A has S, P and W. Case B has S and W but lacks P. Case C has S and P but lacks W. Case D has P and W but lacks S. Under the stated assumptions, only A has every named dependency for reconstructing and unlocking this key. C may permit reconstruction of the protected key, but cannot unlock it without W. B and D lack required reconstruction material.
One of four prepared cases has the complete dependency set: 1 / 4 = 25%. This is a description of these deliberately selected cases, not a recovery success probability or a security score. Even A still requires readable data, correct software behavior and an actual verification step. To test access to an archive, the archive itself must also be present and intact.

Illustrative case study

A fictional AI education business stores old licensed teaching materials in an encrypted archive. Its continuity checklist says that a paper backup exists, and the team initially treats that statement as sufficient.
A rehearsal with test material reveals an incomplete handover. The custodian can locate a sealed page, but the procedure does not identify the corresponding public-key file or explain how the recovery output will be verified. Different staff members assume someone else retains the missing information.
The business rewrites the procedure around named dependencies and assigned responsibilities. It records the result of a controlled rehearsal without copying secret contents into meeting notes. The improvement is a demonstrated recovery process for the tested scenario, not a guarantee against every future loss. This case is invented and describes no real organization's security arrangements.

Common misconceptions and mistakes

Paper is a storage medium, not automatic encryption. A photograph or scan can create another sensitive copy. Conversely, the presence of passphrase protection does not make uncontrolled distribution sensible. Another mistake is preserving a page while losing the encrypted data or other required recovery inputs. A barcode is not mandatory for every paper-key design. Product-specific recovery phrases, printed OpenPGP material and public-key fingerprints should not be assumed to have the same purpose or authority.

Business use

For an AI publishing project, the business question is whether a recovery arrangement supports continuity without making sensitive material unnecessarily accessible. Document the protected asset, responsible custodian, dependencies and evidence of a test. Keep secret contents outside ordinary editorial systems and public documentation. An inventory can record that a package exists and when it was checked without reproducing it. When a process changes, review whether the old recovery package still corresponds to the intended asset and procedure.

Check your understanding

Which rehearsal case has all three named inputs?

Answer: A.

What distinguishes C?

Answer: It lacks the passphrase needed to unlock the reconstructed protected key.

Does 25% estimate real-world reliability?

Answer: No.

Why test beyond finding the page?

Answer: Recovery also depends on other inputs, readability and correct operation.

Related terms

Backup validation
Private key
public key
key backup
recovery phrase
passphrase

Learn next

Draw a dependency diagram for a fictional recovery process using labels only. Mark which inputs are secret and explain what happens when each is missing.

Sources

David Shaw, Paperkey project documentation: https://github.com/dmshaw/paperkey Keybase, Per-User Keys documentation: https://book.keybase.io/docs/teams/puk Product references illustrate distinct meanings. The dependency exercise and publishing case are original teaching examples, not operational recovery instructions.

Previous: Panorama Next: Paradigm (experimental)