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.
The result has approximately 544 bits of displayed phrase search space. This describes the complete displayed phrase representation; it is not a claim that every surrounding account system or attack path has 544-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.