Whitepaper

A short, honest overview of how YGOOW works and, just as importantly, where each protection ends. Nothing here asks you to trust us; it asks you to verify.

1. Design goals

• No identity on the server. No accounts, no phone numbers, no user table. The relay cannot know who talks to whom.
• Access by key, not by permission. Who can read a message is decided entirely by who holds the key — never by a role or a list on our side.
• Metadata minimisation. The network layer (Tor v3) hides your IP and location; the application layer stores only ciphertext and timestamps.
• Honesty about limits. Every layer is documented together with what it does not protect.

2. Identity & key exchange

Your identity is an Ed25519 / X25519 keypair derived locally and held only on your device. A password does not derive the identity — losing the device loses the identity by design.

Conversation keys are exchanged offline by default — in person, by shared file, or by a QR scan — which removes an entire class of man-in-the-middle attacks. A remote, network-assisted exchange is available as a deliberate, clearly-labelled choice, with a fingerprint (safety number) to verify later.

3. Message cryptography — “Variant C”

Each message is sealed with AES-256-GCM under a key derived from your chosen secret:

• passwords run through Argon2id (memory-hard) before use;
• files / links are hashed with SHA3-256;
• there is no key-wrapping and no key hint in the ciphertext. The client simply trial-decrypts with the keys it holds. A wrong key yields a locked block — no error, no oracle.

Because every message can use a different key, the same room looks different to each participant: some lines are text, others are just a lock.

4. Quorum decryption (Shamir)

A message can be split so it only opens when K of N people combine their keys (Shamir’s Secret Sharing over GF(2⁸)). One infiltrator holding one share learns nothing.

5. Forward secrecy

For ongoing conversations a symmetric ratchet advances the key per message, so compromise of one key does not retro-actively expose earlier messages (forward secrecy). Post-compromise security (a full DH ratchet) is a planned hardening step.

6. Transport — onion + store-and-forward

The relay is reachable as a Tor v3 onion service, so the server’s location and your IP are hidden, and the connection is authenticated by the onion address itself. The app can also connect over Tor bridges (for censored networks) or plain clearnet, as a labelled user choice.

Delivery is store-and-forward: messages wait, encrypted, until the recipient reconnects — across a dropping Tor circuit and without either party being online at the same moment. The server keeps no per-recipient state; the client carries its own cursor.

7. Traffic analysis — the metadata that remains

A deaf relay hides content and who-talks-to-whom — but nothing that actually delivers messages can hide that traffic exists at all. We’d rather name what’s left than imply it’s nothing.

The relay can still observe timing (when a block is uploaded or fetched — over Tor the source is hidden, the event is not), size (blocks are stored close to their true length, capped at 64 KB per frame; we do not yet pad to a fixed size), and volume (how many blocks exist, and how often the store is polled).

None of this links a sender to a recipient — the relay sees neither, and keeps no per-recipient state. But a global passive adversary who can watch both ends of a Tor circuit at once can attempt timing correlation; that is a known limit of every low-latency anonymity network, not something specific to us. Fixed-size padding and cover traffic are on the roadmap as opt-in hardening — both trade bandwidth for resistance.

The honest summary: YGOOW makes who you are and what you said unavailable, and who you talked to unprovable from the server alone. It does not claim to beat an adversary who already watches the entire network — no usable messenger does.

8. What YGOOW does not protect

• A compromised device. Spyware, or a phone taken while unlocked, reads your screen regardless of any cryptography. No messenger survives this.
• The fact that you run the app. YGOOW hides content and metadata, not the existence of the app on your phone.
• Endpoint key hygiene. Weak shared secrets, or keys handed to the wrong person, defeat the math.

We state these plainly — because the projects that don’t are the ones you shouldn’t trust.

9. Verify, don’t trust

The cryptography is implemented against known-answer test vectors and a reference implementation. As the project matures we will publish the protocol specification and seek independent review.

Appendix — cryptographic parameters

The exact primitives, as implemented in the reference and ported verbatim to the client. Every domain-separation salt is constant by design: a shared key must reproduce the same bytes on every device, so a per-device salt is not an option — and the secrecy of these salts is not what provides security (it never is). Known-answer test vectors pin every value below.

Message AEAD (“Variant C”)

• blob = nonce(12) ‖ AES-256-GCM(K, nonce, plaintext); 16-byte GCM tag; no key hint anywhere in the block.
• K = SHA3-256(key_material).
• Nonce: 96-bit, random per message. The random-nonce birthday bound is ≈2³² messages per key — comfortable for the short-session profile, and the reason long-lived conversations use the ratchet rather than one static key.

Key material

• Password → Argon2id, salt ygoow/redact/argon2/v1, time = 3, memory = 64 MiB, parallelism = 1, 32-byte output. Memory-hardness is what blunts precompute against the constant salt.
• File / text / URL → SHA3-256.
• Combined sources → HKDF-SHA3-256 over length-prefixed inputs (4-byte big-endian prefixes remove the a‖b vs a‖b ambiguity), salt ygoow/redact/combine/v1.

Identity & key exchange

• 32-byte CSPRNG seed → HKDF-SHA3-256 → Ed25519 (signing / fingerprint) + X25519 (ECDH). The seed never leaves the device.
• Remote exchange: X25519 ECDH → HKDF-SHA3-256 bound to both public keys (sorted, so the result is identical for either side).
• Fingerprint / safety number: SHA3-256 over the sorted pair of Ed25519 keys → 8 groups of 5 digits.

Forward-secrecy ratchet

• Symmetric KDF chain (HKDF-SHA3-256, salt ygoow/redact/ratchet/v1), a separate chain per direction.
• mk_n = HKDF(ck_n, "mk"), ck_{n+1} = HKDF(ck_n, "ck"); used keys are erased (forward secrecy). The 4-byte message number is bound as AEAD associated data; out-of-order delivery is tolerated up to 1000 skipped keys; replays are rejected.
• No post-compromise security yet: the current chain key derives all future message keys. PCS requires a DH ratchet — a separate, to-be-verified layer.

Quorum decryption (Shamir)

• Secret sharing over GF(2⁸) (AES reduction polynomial 0x11B), byte-wise, K-of-N with 1 ≤ K ≤ N ≤ 255. Any K−1 shares reveal nothing. Shares are generated from the secret and distributed offline.

Every value above is exercised by known-answer test vectors, and the app’s on-device self-test re-runs them — so you can confirm the math on your own phone, not just take our word for it.

Living document, v0.1 — the full protocol specification will follow as YGOOW matures.