AKADATA LIMITED
AIP-56 Human Recovery Key v0.0.5
Official AIP-56 documentation, signed v0.0.5 downloads and self-contained reference implementations with native embedded compressed chunk data for a human-readable recovery phrase.
Official AKADATA documentation · v0.0.5
AIP-56 Human Recovery Key
A human-readable, case-sensitive recovery phrase designed to keep a very large recovery secret under the account holder’s control.
What AIP-56 is
AIP means AKADATA Improvement Proposal. AIP-56 is a human recovery key format: a large recovery secret represented as words that a person can print, store, read and re-enter without depending on email, a particular device or an online account.
The current reference produces a phrase containing 15 five-letter words. Every character is independently assigned an upper- or lower-case form using cryptographically secure randomness.
Correction, 27 September 2026: the search-space figure published here was wrong. We previously stated approximately 544 bits of displayed phrase search space. That was a mistake on our part. 544 is twice a simple independent-words estimate — 2 × (15 × log₂ 9074 + 75) = 544.4 — so the estimate was counted twice. It overstated the real search space by about 274 bits, a factor of roughly 2 × 1082.
Counted exactly from the canonical 9,074-word list and the reference selection algorithm, the displayed phrase has a search space of approximately 270 bits: 2270.47, or about 2.6 × 1081 possible phrases. The 75 mixed-case bits are included in that total. The 14 spaces between words are fixed delimiters and contribute no randomness at all.
This corrects how we described the size of the format. The format itself is unchanged: the wordlist, the selection algorithm, the 15-word phrase length and every released reference implementation are exactly as published, and no existing recovery key is affected. Even the most probable valid phrase still carries about 241 bits of min-entropy, so this was an error in our description rather than a weakness in the scheme. As before, this figure describes the displayed phrase representation only; it is not a claim that every surrounding account system or attack path has 270-bit security.
Try it: generate a live AIP-56
Because the reference implementations are self-contained, they can generate a real phrase with no external wordlist file. The PHP class generates on the server (Aip56::selfContained()); the ECMAScript module generates entirely in your browser with Web Crypto. Each button runs up to 10 times per visit, then stops.
Results appear in a panel at the bottom right. These are random examples — do not use them as recovery keys.
Why it exists
Account recovery is often tied entirely to an email mailbox or a device. AIP-56 provides an independent value that the account holder can keep offline and retain under their own control.
It is deliberately human-readable without being a normal sentence, password hint or short recovery code. The reference algorithm balances selection across all initial letters and uses cryptographically secure randomness throughout.
How the phrase works
The canonical source contains 9,074 validated five-letter words grouped by their first letter. The picker selects two distinct words from every a–z group, producing a 52-word candidate pool. It securely shuffles that pool, takes 15 words, and then applies secure random case to every character.
Word order matters. The spaces between words matter. Every character’s case matters. For example, lodge, LODGE and lODgE are different recovery values.
A phrase must be recorded and re-entered exactly as generated. It should be kept private and offline where practical.
Self-contained implementations (native embedded model)
The AIP-56 reference implementations are self-contained. Each runtime implementation embeds the compressed canonical chunk data directly in its own native structure — a PHP array, a frozen JavaScript object, a Python dict, Go structs, C structs, a Ruby frozen Hash, a Lua table and so on. No implementation reads an external wordlist file at runtime.
The embedded data is not plain words and it is not an expanded wordlist. The chunk field named words contains compressed base64 raw-DEFLATE token streams, not decoded words. Each implementation inflates and validates that data in memory before generating a phrase.
Every implementation validates the chunk counts, raw lengths, per-chunk SHA-256 checksums, the total word count and the global checksum. The PHP implementation can additionally reconstruct the canonical JSON byte-for-byte for OpenPGP verification.
Canonical source, integrity and authenticity
The signed wordlist.json is the canonical wordlist source. Its SHA-256 is ea0be8d452c422f154358b386c0c5bfc1f4e8e0670f9cd4ddf1a662cb3c96ec8, and the PHP implementation reconstructs the same canonical JSON byte-for-byte to produce that exact digest.
Checksums prove internal integrity. They detect corruption, invalid token streams, incorrect chunk lengths or inconsistent content. OpenPGP proves AKADATA release authenticity. OpenPGP verification remains tied to the canonical JSON artifact and the AKADATA signing key 7915B0831DF20BAFF4218F347D88C5B374E65D90 (Andrew Smalley <andrew.smalley@akadata.ltd>).
The reference code is published in multiple languages so implementations can be checked and compared against the canonical PHP behaviour. PHP remains the canonical self-contained reference.
No database dependency
AIP-56 generation and validation do not require a database, cookie, session, remote service or network request.
This AKADATA website uses a local privacy-light SQLite counter for page and download statistics only. That counter is part of this website, not the AIP-56 format, algorithm or reference implementation.