Keys

This document sets out, for the Hahoe Genesis Protocol (HGP), what locks the original, who opens it, and what happens when a key is lost or the depositor dies. It is how principle 3, “It does not open without the owner’s key”, is kept in practice.

---

0. In one line

Each original file is locked with its own key, and that key is wrapped again with the depositor’s key. The depositor’s key is split into three shares held by three parties, and it comes back only when two of them come together: the depositor’s device, the family (successor), and Nodeone. Nodeone cannot open anything alone, and the depositor has nothing to memorize.

1. What this protects

1. Nodeone cannot open an original alone (principle 3). The same holds for the store operator, for someone who breaks into the server, and for anyone who demands the material from Nodeone.
2. The depositor does not have to think about keys (HGP-0005 section 2). We do not make them memorize a recovery phrase or guard a piece of paper. They open things with the phone’s fingerprint or face recognition.
3. Losing the phone does not mean losing the records. The family and Nodeone recover them together.
4. Sealed is the depositor alone. Neither the successor nor the family member who helped with recovery can open it (00-Principles section 3).
5. We write down separately which stretches are guarded by lock and which are guarded by promise (01-Permissions section 1, item 4). They are gathered in section 7 of this document.

2. Kinds of keys

Key	What it does	Where it is	September specification
Content key	Locks one original file. A random key made fresh for each file	Wrapped, in the store’s key ledger
Owner key	Wraps the depositor’s content keys (except sealed ones). The signing key is also derived from it	Inside the depositor’s device. Three shares for recovery (section 4)	the person’s key
Relation key	Opens one scope (relation, community). Wraps the content keys in that scope once more	Wrapped with the owner keys of the people in that scope	the relation’s key
Seal key	Wraps the content keys of sealed records	On the depositor’s device, and in one place not connected to the internet. It is not split into shares	cold (section 5)
Signing key	The depositor signs fingerprints with it (section 5)	Derived from the owner key

• The “app key” (decision 0011) is not one of the keys in this document. It is the pass an app uses to get into the store, and it cannot unlock an original.
• The path to open one file: the device’s fingerprint or face recognition → owner key → that file’s content key → original. For a relation scope, it passes through the relation key once more.

3. When and where to lock

• Lock on the device, then send. When a recording ends, the device takes the original fingerprint (sha256_device), locks the file with the content key, takes the fingerprint of the locked file as well, and then sends it. The store only receives locked files.
• The store takes the fingerprint of the locked file (stored fingerprint, sha256_stored) and checks it against the value the device sent. If they differ, it does not store the file (the “take it twice” rule of 02-Fingerprint section 2 is applied to the locked file).
• The store cannot see the original, so it cannot take the original fingerprint again. When the device locks the file, the original fingerprint (sha256_store) records the value the device took, as it is. Checking the original fingerprint again is done by the depositor’s device each time it opens the file (02-Fingerprint section 4).
• The ledger records encryption: "user-key" and event: "encrypted" (03-manifest sections 3 and 5).
• When the device cannot lock the file (for example, a batch of old document scans already made), the store locks it as soon as it receives it and deletes the copy from before locking. From the moment of receipt until it is locked, it is guarded by promise.

4. Two of three: recovery and succession

The owner key is split into three shares. Any two shares bring the owner key back, and one share alone reveals nothing (Shamir’s secret sharing). Decided by the head of Nodeone (2026-10-13, decision 0018).

Share	Who holds it	How
1	Depositor	Inside the device (together with the owner key itself)
2	Family (successor)	If the family member uses the app, wrapped with that person’s owner key. Otherwise on a paper card (QR)
3	Nodeone	Locked with Nodeone’s key, in a place separate from the data. Copies follow the two-places rule for originals (decision 0010)

• If no family member is named, the depositor’s second device (another phone, a computer, a security key) takes the place of share 2. If there is neither, the records cannot be recovered when the phone is lost. We tell the depositor this at the start.
• By default, the family member who holds share 2 is the successor. This can be set differently.
• A share is used only to bring a key back. The family member who holds a share cannot open anything with it alone.

Recovery (the depositor is alive and has lost the phone)

1. The depositor asks for recovery from a new device. Nodeone checks their identity.
2. The family member sends their share to the new device.
3. Wait 7 days. During that time, the depositor’s other devices and the family are notified. If someone asked while pretending to be the depositor, it can be stopped in that time.
4. Nodeone sends its share to the new device. The owner key comes back only inside the new device. Nodeone and the family never see each other’s shares.
5. The new device makes a new owner key and splits it into shares again (the old shares become useless).
6. The fact and time of the recovery remain as an entry that is never deleted (HGP-0005 section 10).

Succession (the depositor has died)

It follows the procedure in 01-Permissions section 2 as it is: confirmation of death, identity check of the successor, a waiting period, and a record of the execution. The waiting period is 30 days. After that, the owner key is brought back on the successor’s device from the successor’s share and Nodeone’s share.

• The successor opens everything except sealed. The seal key is not in the shares, so succession does not open it (00-Principles section 3, “Not even the successor can open it”).
• Succession does not change scope. The successor cannot widen a scope (01-Permissions section 2).

If Nodeone ceases to exist, share 3 is handed to the next trustee. What is handed over is the share, and the handover is recorded (HGP-0003 Article 10, HGP-0005 section 8-1). Even before the handover, the depositor’s device and the family share, two together, are enough to split the key again.

5. Signatures

This settles the “depositor signature” left open in 02-Fingerprint section 8 (decision 0018).

• Ed25519 (RFC 8032). The signing key is derived from the owner key (HKDF, RFC 5869) and is used only inside the device.
• What is signed: the record’s original fingerprint, the record number, and the time. It is proof that “this person deposited this record”.
• The public key is kept in the store. Each time it changes (recovery, succession), the new public key and the reason are kept as an entry that is never deleted.
• The C2PA approach (X.509 certificates) will be looked at again when an institution is the depositor.
• It is different from the store signature on registry entries (secp256k1, decision 0016). That one is the store’s signature saying “we posted it”.

6. Scope and keys

• Widening a scope = wrapping the content key once more with a new relation key. The original is not moved (HGP-0005 section 6).
• Narrowing a scope = removing that wrapped copy. What someone who already opened it has taken away cannot be withdrawn (07-Deposit section 7).
• Public = the original stays locked, and only a copy for the public (a reduced copy, with location data removed) is kept separately, unlocked. The copy carries which original it was made from and how (02-Fingerprint section 9).
• Sealed = wrapped only with the seal key. The wrapped key is not kept on an online server (HGP-0005 section 5, “cold”).
• Destruction = removing every wrapped copy of that record’s content key (01-Permissions section 4). Copies left in backups of the key ledger disappear only after the backup rotation period passes. That period (for example, 30 days) is written in the destruction entry. The locked file may remain, but no one can open it.

7. The moment it opens: stretches guarded by promise

Stretch	What opens	How it is guarded
When the original is sent to an outside company, as for transcription or translation	For each job, the depositor’s device briefly hands that file’s content key to the server. The server unlocks it only in memory to send it, leaves nothing on disk or in logs, and discards it when the job ends. If “automatic transcription” is on, the device sends this permission along when the recording ends	Promise. At that moment, the unlocked original is in server memory. The record of sending is sent_to (03-manifest section 8)
When the device cannot lock, and the store locks on receipt	From the moment of receipt until it is locked	Promise
The interpretive layer (transcripts, translations, summaries)	Not locked for now. It is filtered and shown according to scope	Promise. Locking of the interpretive layer will be decided again before secretary v1
Reading copies for public and community scopes	Not locked (HGP-0005 section 5, “hot”)	Scope filtering
Recovery	If Nodeone and the family conspire, they can bring back the owner key without the depositor	Promise, the 7-day notice, and the record that is never deleted

This table is the answer to 01-Permissions section 6, item 1 (“the moment the original is unlocked for transcription”). We do not use a path that sends directly from the phone to the transcription company. The transcription company’s key (API key) cannot be kept on the phone.

8. Where things stand now

Where	Locking	When
secretary	Not locked (encryption: "none"). Guarded only by promise	Following this document in v0.2 (11/16)
arkive	Not locked. Guarded only by promise	The receiving side first, when secretary starts depositing locked originals (decision 0004). arkive’s own depositor keys will be decided after the login version
provenance	Not locked. Most of it is photos meant to be public	When it is merged into arkive (2027-02)

9. Recommended methods (implementation is free to choose)

As in HGP-0005 section 11, this document sets what must be kept, and the implementation chooses the technology. What we recommend for secretary v0.2:

Task	Recommended method	Grade
Opening the owner key on the device	The PRF extension of W3C WebAuthn (passkeys)	referenced
Locking files	AES-256-GCM or XChaCha20-Poly1305	referenced
Wrapping keys	HPKE (RFC 9180)	referenced
Splitting into shares	Shamir’s secret sharing (two of three)	referenced
Signing	Ed25519 (RFC 8032), key derivation HKDF (RFC 5869)	referenced
Destruction	NIST SP 800-88 “cryptographic erase” (destroying the key so that it is the same as erasing)	referenced

We do not write “conforms” until it has been checked with a test tool. There is not yet an international standard that covers keys and deposit (the September external standards mapping).

10. To check

1. Whether passkey PRF works in the web app (PWA) on the phones secretary uses (Android, iPhone). If it does not, v0.2 starts with key storage inside the device, and the difference is written down.
2. When a family share is given on a paper card, the procedure for giving a new share to a family member who lost the card.
3. Legal guardianship (01-Permissions section 6, item 2): when the depositor is alive but can no longer make decisions on their own, whether recovery or succession applies.
4. What to give ordinary users as the “place not connected to the internet” for the seal key (a security key, paper).