#Key and Hash Sizes

The Encoding Primer showed how binary bytes become readable text through Base16, Base64, and Base58. The Post-Quantum Cryptography page explained why Avatarnet chose its five algorithms and why they produce keys and signatures that are dramatically larger than classical alternatives. This page puts both together: every key, hash, and signature in the protocol, with its exact size in bytes and in the encodings you will encounter on the wire.

Before looking at the sizes, it helps to understand what these cryptographic objects actually are and what role each one plays.

#What is a public key?

A public key is a piece of data you share with the world. It is published alongside your .avtr domain so that anyone can look it up. Its only job is verification: given a signature and a message, the public key lets anyone confirm that the message was signed by the holder of the corresponding private key. The public key cannot sign anything, and knowing it does not let you forge signatures or impersonate the owner.

#What is a private key?

A private key is the secret half of the keypair. It never leaves your device. Its job is signing: it takes a message and produces a signature that only this specific private key could have created. Anyone who has the public key can verify the signature, but nobody can work backwards from the signature to discover the private key.

#What is a signature?

A signature is proof of authorship. It is a piece of data produced by combining a message with a private key. It answers one question: did the owner of this keypair approve this exact message? If even a single character of the message changes, the signature becomes invalid.

#What is a hash?

A hash is a fingerprint. It takes any input, regardless of length, and produces a fixed-size output. The same input always produces the same hash. Different inputs produce different hashes. And there is no way to recover the original input from the hash. On Avatarnet, the hash of an engram becomes its permanent address.

#How they work together

You write an engram:

  1. SHA-512(content)              → Content hash      (the address)
  2. Sign(hash, private key)       → Signature         (proof you wrote it)
  3. Publish: [content + hash + signature]

Anyone verifies it:

  1. SHA-512(content)              → Recalculate hash  (does it match?)
  2. Verify(signature, public key) → Valid?            (did the author sign it?)

No secrets needed to verify. The public key and the content are enough.

Everything below is organized around the two concepts introduced on the Avatar & Mind page. Your Avatar is the body, protected by one cryptographic pillar. Your Mind is everything the body holds, protected by three more.

#👤 Avatar (the body)

The Avatar is your cryptographic identity, a single keypair that signs every engram you write and every update you make. It has one pillar to protect it, and the sizes below are what that pillar actually looks like on the wire.

#👤🪪 Avatar Identity

This avatar is you.

The public key is what the Avatar Name System stores alongside your .avtr domain, so that anyone looking up einstein.avtr can retrieve the same 64 bytes and verify any signature you have ever produced. The private key never leaves your device.

#🧠 Mind (what the body holds)

The Mind is everything you write or record about yourself, stored as engrams: stories, lessons, memories, anything you want preserved. Three pillars protect it, one for authorship, one for integrity, and one for privacy. Each pillar has its own algorithms and its own sizes, and they are shown separately below so it is easy to see which bytes are doing what.

#🧠✍️ Mind Authorship

You wrote this engram.

Every engram, memory, and experience your Avatar publishes carries a signature produced by the same SLH-DSA private key that defines the Avatar itself. The signature is what proves authorship to anyone who later reads your words, and it is dramatically larger than a classical signature because post-quantum hash-based signing requires far more data to remain secure.

For context, Ed25519 (the algorithm used by Bitcoin, Signal, and SSH) produces 64-byte signatures. SLH-DSA signatures are roughly 780 times larger, which sounds extreme until you remember that the smaller signatures have an expiration date measured in years, while the larger ones are expected to hold up for decades beyond the arrival of practical quantum computers.

#🧠🔗 Mind Integrity

Your words unchanged, backed up forever.

Integrity is what guarantees that a single character of your engram cannot be altered without the network noticing immediately. Every engram, memory, and experience is hashed with SHA-512, and that hash becomes its permanent content address. Change anything and the hash changes, and every parent in the hierarchy changes with it.

The hash itself is small, yet it is the foundation on which all the larger structures rest, because every signature ultimately signs one of these 64-byte fingerprints rather than the full content.

#🧠🔐 Mind Privacy

Only you can read it.

Privacy applies to any engram you mark private or personal. The content is encrypted with AES-256-GCM so that even the nodes hosting it cannot read a single word, and the encryption key is exchanged using ML-KEM-1024, a post-quantum key encapsulation mechanism that replaces classical Diffie-Hellman approaches like X25519.

The AES key itself stays small, but the ML-KEM structures that let two Avatars agree on that key are significantly larger than their classical predecessors. That extra weight is another consequence of choosing algorithms that will outlast quantum computers, and it is the same tradeoff the authorship signatures make, just expressed in a different shape.

#What you see on screen

#Avatarnet's addressing model

Avatarnet:  chatp://einstein.avtr             (human-readable domain)
                     │
                     ↓  DHT lookup
            public_key:a1b2c3d4...            (SLH-DSA public key)
                     │
                     ↓  DHT lookup
            [PeerID@oxfordarchive.node]       (where the data lives)

Like DNS:   google.com  →  142.250.80.46      (human name → IP)
Like us:    einstein.avtr → key → node        (human name → key → location)

Users rarely see raw keys in daily use, because the Avatar Name System maps human-readable .avtr names to cryptographic identities behind the scenes. Encoding matters most under the hood, where keys need to travel through URLs, configuration files, QR codes, and paper backups without losing a single bit along the way.

#How a Peer ID is constructed

Avatarnet uses libp2p for peer-to-peer networking, and every node on the network needs a Peer ID that other nodes can use to find and verify it. The Peer ID is derived from the node's SLH-DSA public key through a standardized sequence of steps.

Peer ID = base58btc( multihash( SHA-256( protobuf( public_key ) ) ) )

Steps:
  1. Take SLH-DSA public key                     (64 bytes)
  2. Wrap in protobuf CryptoKey                  (~68 bytes, adds type + length prefix)
  3. SHA-256 hash the protobuf                   (32 bytes)
  4. Prepend multihash header                    (34 bytes, 0x12 SHA-256 + 0x20 length)
  5. Encode as base58btc                         (~46 characters)

Step 3 is where Avatarnet's post-quantum keys change the construction. With classical ed25519 (32 bytes), the protobuf-wrapped key is only 36 bytes, small enough to embed directly using an identity multihash. That skips the hash step entirely and produces the familiar 12D3KooW... prefix that libp2p users recognize. SLH-DSA's 64-byte public key pushes the wrapped result past libp2p's 42-byte inline threshold, so the key is SHA-256 hashed before encoding. The result is shorter than the raw key but no longer contains the key itself, only a fingerprint of it.

In multiaddr format, a node's full network address combines its IP, port, and Peer ID into a single string:

/ip4/198.51.100.0/tcp/4242/p2p/QmYwAPJzv5CZsnN...

This is the address that the distributed hash table stores when resolving a .node name like oxfordarchive.node to the machine that actually holds the data.