#Signing and Encryption

The Key and Hash Sizes page laid out every key, signature, and hash Avatarnet produces and exactly how large each one is. This page steps inside those numbers: how each of the five algorithms actually works, what goes in, what comes out, and when each one fires during normal protocol operations.

#SLH-DSA-SHA2-256f (FIPS 205)

SLH-DSA is the algorithm that signs everything on Avatarnet. It proves that you created your Avatar, that you wrote a given engram, and that every update to your public record came from you and nobody else. It upholds two of the four pillars: Avatar Identity and Mind Authorship.

#What it does

SLH-DSA is a digital signature scheme. It takes a message and a private key as input and produces a signature as output. Anyone who has the corresponding public key can verify that the signature is valid without ever seeing the private key. This is the fundamental asymmetry that makes public-key cryptography work: signing requires a secret, but verification is open to the world.

#How it works

Most signature algorithms rely on algebraic trapdoors, mathematical structures that are easy to compute in one direction and hard to reverse. Elliptic curve schemes use the difficulty of the discrete logarithm problem. Lattice-based schemes use the difficulty of finding short vectors in high-dimensional spaces. SLH-DSA takes a different approach entirely: it builds signatures from hash functions and nothing else.

The construction is a hierarchy of Merkle trees. At the lowest level, SLH-DSA generates a large number of one-time signature keypairs, each capable of signing exactly one message. These keypairs are organized into the leaves of a Merkle tree, where each parent node is the hash of its two children. The root of the tree serves as the public key. To sign a message, the algorithm selects an unused one-time keypair, signs the message with it, and includes the authentication path from that leaf to the root, the chain of sibling hashes that proves the leaf belongs to the tree.

The "stateless" in SLH-DSA's design means that the signer does not need to remember which one-time keypairs have already been used. Instead, it uses a pseudorandom function seeded by the message and the secret key to deterministically select which keypair to use for any given message. This avoids the catastrophic risk of reusing a one-time signature, which would leak the private key, without requiring the signer to maintain state.

Private key + Message
      ↓
  Pseudorandom selection of one-time keypair
      ↓
  Sign message with one-time key
      ↓
  Include authentication path (leaf → root)
      ↓
  Signature = one-time signature + Merkle path

Because the entire construction is built from hash evaluations, its security reduces to a single assumption: that the hash function is one-way. There are no lattice problems to solve, no number-theoretic shortcuts to discover, and no algebraic structure for a future breakthrough to exploit.

#The tradeoff

The cost of this approach is size and speed. Every signature must include the one-time signature plus the full authentication path through the Merkle tree, which is why SLH-DSA-SHA2-256f signatures are 49,856 bytes, roughly 780 times larger than Ed25519's 64-byte signatures. Signing requires many sequential hash evaluations, which is why it takes 205 milliseconds compared to Ed25519's 0.05 milliseconds. Verification is fast at 5.2 milliseconds, because the verifier only needs to recompute the hash path and check it against the public key.

#Variant decisions

SLH-DSA-SHA2-256f is not the only variant that FIPS 205 defines. The name encodes three decisions:

• SHA2 (not SHAKE): Both hash families provide identical security. SHA-2 is 1.5 times faster on most hardware because modern processors include dedicated SHA-2 acceleration (Intel SHA-NI, ARM SHA2 instructions). SHAKE, which is built on the SHA-3/Keccak family, has no equivalent hardware support on most current CPUs.
• 256 (not 128 or 192): This is NIST Security Level 5, the maximum available, equivalent to 128-bit quantum security. Level 1 and Level 3 are faster and produce smaller signatures, but Avatarnet does not compromise on security level.
• f (not s): The "fast" variant signs in 205 milliseconds but produces 49,856-byte signatures. The "small" variant produces 29,792-byte signatures but takes 1,920 milliseconds to sign, nearly ten times longer. For a system where users publish engrams one at a time, 205 milliseconds is acceptable. 1.9 seconds is not.

#SHA-512 (FIPS 180-4)

SHA-512 is the algorithm that gives every piece of content on Avatarnet a permanent address. It upholds the third pillar: Mind Integrity.

#What it does

SHA-512 is a cryptographic hash function that takes an input of any length, from a single character to an entire book, and produces a fixed 64-byte (512-bit) output called a digest or hash. The same input always produces the same hash, even the smallest change to the input produces a completely different hash, and there is no known way to work backwards from a hash to recover the original input.

#How it works

The input is padded to a multiple of 1024 bits, then processed in blocks through 80 rounds of bitwise operations: shifts, rotations, additions, and logical functions. Each round mixes the current block with the accumulated state from all previous blocks, so the final hash depends on every single bit of the input. The output is the 512-bit state after the last block has been processed.

Input (any length)
      ↓
  Pad to 1024-bit blocks
      ↓
  Process each block through 80 rounds
      ↓
  64-byte hash (always the same length)

#Why it matters for content addressing

In a traditional database, you store a record and the database assigns it an ID, a number that has no connection to the content itself. If someone changes the content, the ID stays the same, and you have no way to know anything was altered.

Content addressing inverts this. The hash of the content is the address. If someone changes a single character of an engram, the hash changes, and the address changes with it. The original address now points to nothing, and anyone who recalculates the hash of the modified content will get a different result. Tampering is not just detectable; it is mathematically self-evident.

This is also why SHA-512 and signatures serve different purposes. A signature proves who wrote something. A hash proves what was written. Both travel with every engram:

Engram content → SHA-512 → Content address (where to find it)
Engram content + Private key → SLH-DSA → Signature (who wrote it)

Stored together: [Content] + [Hash] + [Signature]

A verifier recalculates the hash to confirm the content has not changed, and checks the signature against the author's public key to confirm the author's identity. Neither check requires access to any secret.

#Why SHA-512 and not SHA-256

SHA-256 produces a 256-bit hash with 128-bit quantum security (Grover's algorithm halves the security bits). SHA-512 produces a 512-bit hash with 256-bit quantum security. Both are impossible to break, but content addresses are permanent. They cannot be upgraded later because the hash is the address itself. If Avatarnet used SHA-256 today and needed to move to SHA-512 in the future, every address in the network would change. The extra 32 bytes per hash is a trivial cost for a margin that can never be regained.

#AES-256-GCM (FIPS 197)

AES-256-GCM is the algorithm that encrypts private and personal engrams so that only the intended recipient can read them. It upholds the fourth pillar: Mind Privacy.

#What it does

AES-256-GCM is a symmetric encryption algorithm, meaning the same key both encrypts and decrypts the data. It is an Authenticated Encryption with Associated Data (AEAD) scheme, which means it provides both confidentiality (nobody can read the ciphertext without the key) and integrity (any modification to the ciphertext is detectable on decryption). If a single bit of the encrypted data is changed, decryption fails entirely rather than producing corrupted output.

#How it works

AES (Advanced Encryption Standard) operates on 128-bit blocks of data using a 256-bit key. GCM (Galois/Counter Mode) wraps AES in a construction that turns it into a stream cipher: it generates a keystream by encrypting a sequence of counters, then XORs that keystream with the plaintext. Each encryption operation requires a unique 96-bit nonce (number used once). Reusing a nonce with the same key would compromise both confidentiality and integrity, so Avatarnet generates a fresh random nonce for every engram.

Plaintext + Key + Nonce
      ↓
  AES encrypts counter blocks → Keystream
      ↓
  Keystream XOR Plaintext → Ciphertext
      ↓
  GCM computes authentication tag
      ↓
  Output: Ciphertext + Tag + Nonce

The authentication tag is a short value computed over both the ciphertext and any associated data (such as the engram's content address). On decryption, the recipient recomputes the tag and if it does not match, the data has been tampered with and decryption is refused.

#Quantum security

AES-256 provides 128-bit quantum security. Grover's algorithm could theoretically search a 256-bit keyspace in 2^128 operations instead of 2^256, but 2^128 operations remain physically impossible. AES-256 is the standard symmetric cipher for classified information in the United States and has no known practical weakness.

#ML-KEM-1024 (FIPS 203)

ML-KEM-1024 is the algorithm that lets two Avatars agree on a shared secret across an untrusted network. It enables the Mind Privacy pillar by solving a problem that AES-256-GCM cannot solve on its own: how do two parties who have never communicated before arrive at the same encryption key?

#What it does

ML-KEM is a Key Encapsulation Mechanism. Unlike classical key exchange algorithms such as Diffie-Hellman, which produce a shared secret through an interactive exchange, ML-KEM works in a single round. One party encapsulates a secret inside a ciphertext using the other party's public key. Only the holder of the corresponding private key can decapsulate the ciphertext and recover the shared secret. Both parties now hold the same AES-256 key without it ever having crossed the network in the clear.

#How it works

ML-KEM's security is based on the Module Learning With Errors (MLWE) problem, a lattice-based mathematical structure that is believed to be hard for both classical and quantum computers. The encapsulation process generates a random secret, encrypts it against the recipient's lattice-based public key, and produces a ciphertext that only the recipient's private key can unwrap.

Alice wants to send a private engram to Bob.

1. Alice fetches Bob's ML-KEM public key from the DHT
2. Alice generates a random shared secret
3. Alice encapsulates: ML-KEM(secret, Bob's public key) → Ciphertext
4. Alice encrypts the engram: AES-256-GCM(engram, shared secret) → Encrypted engram
5. Alice sends: [Encrypted engram + Ciphertext]

Bob receives:
1. Bob decapsulates: ML-KEM(Ciphertext, Bob's private key) → Shared secret
2. Bob decrypts: AES-256-GCM(Encrypted engram, shared secret) → Engram

ML-KEM-1024 is NIST's Level 5 parameter set, providing 128-bit quantum security. The public key is 1,568 bytes and the ciphertext is 1,568 bytes, significantly larger than classical X25519 (32 bytes each), but that extra size is the price of post-quantum key agreement.

#Argon2id (RFC 9106)

Argon2id is the algorithm that protects your private key on your device. It is internal to the client and invisible to the network, but it is the first line of defence if someone gains physical access to your machine.

#What it does

Argon2id is a password-based key derivation function. It takes a human-chosen password and transforms it into a cryptographic key suitable for encrypting your SLH-DSA private key at rest. The transformation is deliberately slow and memory-intensive, so that an attacker who steals the encrypted private key cannot simply try billions of password guesses per second.

#How it works

Argon2id fills a large block of memory with pseudorandom data derived from the password, then makes multiple passes over that memory, mixing blocks in a pattern that depends on both the password and the memory contents. The "id" variant combines two approaches: data-independent memory access patterns (which resist side-channel attacks) for the first pass, and data-dependent patterns (which resist GPU-based brute force) for subsequent passes.

The key parameters are:

• Memory cost: How much RAM the function requires. More memory means an attacker needs more hardware per guess.
• Time cost (iterations): How many passes over memory. More passes mean each guess takes longer.
• Parallelism: How many threads run simultaneously.

Because the function is memory-hard, an attacker cannot gain a significant speedup by using GPUs or custom hardware. Each guess requires the full allocation of memory, which makes large-scale brute-force attacks economically infeasible.

#Public vs Private: Two Security Models

Content addressing and encryption solve different problems. Avatarnet uses both, but in different places.

#Public content (wiki engrams, bio, chat history)

No encryption. The content is meant to be read by everyone. Protection comes from immutability (content addressing) and authorship (signatures).

Author writes engram:

  1. Write plaintext                           "E=mc²"
  2. SHA-512(plaintext)                      → content address (CID)
  3. Sign CID with avatar's private key      → signature

Replicate {plaintext, CID, signature} across nodes.

Anyone can:
  ✓ Read the content                          (it is public)
  ✓ Verify integrity: SHA-512(content) == CID
  ✓ Verify authorship: signature valid for avatar's public key

Nobody can:
  ✗ Tamper with content                       (hash would change)
  ✗ Forge authorship                          (need avatar's private key to sign)

#Private content (DMs, private memories)

Encrypted with AES-256-GCM. Nodes store and replicate data they cannot read. Only the intended recipient can decrypt.

Alice sends private content to Bob:

  1. Alice fetches Bob's ML-KEM public key     (from DHT / bob.avtr)
  2. ML-KEM encapsulate:
       random secret + Bob's public key      → shared secret + ciphertext
  3. Encrypt plaintext with AES-256-GCM:
       plaintext + shared secret + nonce     → encrypted blob + auth tag
  4. SHA-512(encrypted blob)                 → CID
  5. Sign CID with Alice's private key       → signature
  6. Replicate {encrypted blob, ciphertext, CID, signature} across nodes

Nodes can:
  ✓ Verify integrity: SHA-512(blob) == CID
  ✓ Verify authorship: signature valid for Alice's public key
  ✓ Store and replicate the blob

Nodes CANNOT:
  ✗ Read the content                          (encrypted, no key)

Only Bob can:
  ✓ Decapsulate the shared secret             (needs his ML-KEM private key)
  ✓ Decrypt with AES-256-GCM                  (needs the derived key)
  ✓ Read the plaintext

#Side by side

Public space (.avtr wiki/chat)       │  Private space (DMs, private memories)
─────────────────────────────────────┼──────────────────────────────────────────
Content addressing → immutability    │  Content addressing → immutability
SLH-DSA signature  → authorship     │  SLH-DSA signature  → authorship
No encryption      → anyone reads   │  AES-256-GCM        → only recipient
                                     │  ML-KEM key exchange → shared secret
─────────────────────────────────────┼──────────────────────────────────────────
Tamper-proof, open by design         │  Tamper-proof, encrypted at rest
                                     │  Nodes are dumb pipes, cannot read

#When Each Algorithm Fires

During normal protocol operations, different algorithms activate at different moments. Here is what happens during the four most common operations:

#Create Avatar

1. Generate SLH-DSA-SHA2-256f keypair              [SLH-DSA keygen, ~40 ms]
2. SHA-512(public key) → Avatar address             [SHA-512]
3. Sign avatar record with private key              [SLH-DSA sign, ~205 ms]
4. Encrypt private key with Argon2id-derived key    [Argon2id + AES-256-GCM]
5. Publish avatar record to DHT

#Publish Engram

1. Author writes content
2. SHA-512(content) → Content address               [SHA-512]
3. Sign content with private key                    [SLH-DSA sign, ~205 ms]
4. If private: encrypt with AES-256-GCM             [AES-256-GCM]
   If sharing: ML-KEM encapsulate for recipient     [ML-KEM-1024]
5. Publish to DHT: [Content + Hash + Signature]

#Fetch Avatar (view someone's profile)

1. Look up einstein.avtr in DHT                     [DHT lookup]
2. Retrieve avatar record with public key
3. Verify avatar record signature                   [SLH-DSA verify, ~5 ms]
4. Retrieve list of engram addresses
5. For each engram:
   a. Fetch content from DHT
   b. SHA-512(content) → Compare to address         [SHA-512]
   c. Verify signature with author's public key     [SLH-DSA verify, ~5 ms]
6. Display verified content

#Receive Private Engram

1. Receive encrypted engram + ML-KEM ciphertext
2. Decapsulate shared secret with private key       [ML-KEM-1024]
3. Decrypt engram with shared secret                [AES-256-GCM]
4. SHA-512(content) → Verify content address        [SHA-512]
5. Verify signature with sender's public key        [SLH-DSA verify, ~5 ms]

#Performance Summary

All benchmarks below were measured on consumer hardware in release mode:

Signing is the slowest operation at 205 milliseconds, which is acceptable for publishing one engram at a time. Verification is fast at 5 milliseconds, which means loading a page with 50 engrams takes roughly 250 milliseconds. Everything else runs in under a millisecond.

The cryptography is complete. You now know what protects the Avatar, what protects the Mind, and how each algorithm works. The next question is how all of this travels across the network: how your device finds other nodes, how your data reaches the machines that store it, and how the distributed hash table that underpins everything keeps running without a central server. That is the subject of the next section on peer-to-peer networking.