# Ragnarok / AES512 — security hardening roadmap This is the public plan for taking Ragnarok from "a carefully built research artifact" to "a design a professional cryptographer finds convincing." It doubles as the project's honesty ledger: it states plainly where the security argument stands today, what it would take to move it forward, and the one rule we hold ourselves to about the word *secure*. If you are a cryptographer or security researcher: the fastest way to help is at the bottom — [Open problems](#open-problems--how-to-contribute). Findings, positive or negative, are the entire point of publishing this. ## The claim ladder A new cipher cannot be *proven* secure — AES itself is not. What earns trust is not a bigger number, it is **demonstrated cryptanalytic effort that fails to break it**, sustained over time and in the open. So we grade this project on an explicit ladder and refuse to describe it above its rung: | Level | Meaning | Ragnarok today | |---|---|---| | **L0 — Specified** | Byte-exact spec, reference implementation, pinned test vectors, reproducible build. A stranger can build an interoperable copy and check every vector. | **Reached** | | **L1 — Self-analysed** | The designers have mounted their own best attacks, computed exact bounds by machine, and published claims *and* non-claims. "We did our homework," not "it is secure." | **In progress** | | **L2 — Independently reviewed** | Cryptographers outside the project have studied the design and published findings (positive or negative) — ePrint, an issue, a workshop. | Not started | | **L3 — Publicly cryptanalysed** | Years of open attack effort with no break of the full cipher. The only basis on which *any* cipher, AES included, is actually trusted. | Not started | **The rule we hold ourselves to:** > The words **"audited"** and **"secure"** stay off this project until **L2**. > "Trustworthy for production" means **L3**. Until then the standing > description is *"unaudited research artifact — use AES-256 / Signal for > anything that matters,"* and that sentence appears in the README, the site > footer, `SECURITY.md`, and every doc. This is not modesty for its own sake. It is the difference between a project a serious reviewer engages with and one they dismiss in the first paragraph. ## How to read this `[x]` done · `[ ]` open · **(in progress)** started. Each item says *what*, *why it matters*, rough *effort*, and *who* can do it (**solo** = the maintainer; **collab** = a co-author / the security-PhD collaborators; **community** = external cryptanalysts and reviewers, by definition not us). --- ## Phase 0 — Release hygiene · days · solo Prerequisites for going public credibly. None are research; all are blockers. - [x] **Public git repository** — `github.com/antipolaire/ragnarok`. - [ ] **LICENSE** — Apache-2.0 (its patent grant matters for a cryptographic artifact more than MIT's brevity does). *Added; confirm the choice.* - [ ] **Reporting policy** — a `SECURITY.md` contact (`security@…`) and a one-line coordinated-disclosure note, stating that cryptanalytic results are welcome in public and that negative results will be linked, not buried. - [ ] **Public CI** — GitHub Actions running the whole proof suite on every push: the exhaustive MDS check, KATs + Monte-Carlo chain, fuzz smoke, `vet` (native + wasm), race tests, the two-WASM E2E, and the offline-bundle reproducibility check. A green badge that *proves the proofs still run* is itself evidence a reviewer values. - [ ] **Seed the issue tracker** — file the open problems below (and `SECURITY-ANALYSIS.md` §7) as real issues, labelled `cryptanalysis`, `open-problem`, `help-wanted`. This is the "publicly listed issues" mechanism: the project's weaknesses are tracked in the open, not implied. - [ ] **Publication name** — "AES512" invites dismissal before §1 is read (FIPS 197 is 128-bit only; the name reads as a claim on a standard it is not part of). Choose a distinct name for the paper (the brand "Ragnarok" is available); the Go module path can stay. Blocks the ePrint title. - [x] **Publish this roadmap + ladder** — in the repo and on the site. ## Phase 1 — Self-cryptanalysis & implementation evidence · weeks · solo + standard tooling The bulk of **L1**. Each item is mechanical for someone who has done it before, and together they are exactly what a symmetric-crypto reviewer opens the paper expecting to find. "Large margin" (what we have) is not "we looked" (what this provides). - [ ] **Exact active-S-box bounds (MILP/SAT)** — replace the theorem-only "≥ 81 active S-boxes per 4 rounds" with a computed table of the *minimum* active S-boxes per round, **differential and linear**, for rounds 1–10, using the standard Mouha–Wang–Gu–Preneel MILP framework. This is the first table a reviewer looks for. **(in progress: model scaffolding)** - [ ] **Integral / division-property distinguishers** — search the longest integral distinguisher over the 8×8 state via Todo's bit-based division property. Reduced-round integral attacks reach furthest on AES-like ciphers, so this is where reviewers probe first. - [ ] **Impossible-differential search** — miss-in-the-middle over the wide-trail structure; report the longest ID and the key-recovery rounds it reaches. - [ ] **Boomerang / rectangle analysis** — bound the best boomerang switch using the S-box Boomerang Connectivity Table. - [ ] **MITM / Demirci–Selçuk assessment** — the key = block = 512-bit shape is unusual; argue meet-in-the-middle and biclique reach explicitly rather than by analogy to AES. - [ ] **Key-schedule positioning** — write up the SHAKE-256 schedule as an independent-round-key key-alternating cipher (iterated Even–Mansour; Chen–Steinberger tight bounds) and state precisely what the SHAKE reduction does and does not buy for related-key security. - [ ] **Constant-time, measured not asserted** — run `dudect` and `ctgrind`/valgrind on amd64 and arm64, and inspect the emitted **wasm** (Go's compiler makes no constant-time promise). Publish the measurements; they turn the source-level claim in `DESIGN.md` §4.4 into data. - [ ] **Avalanche / SAC statistics** — strict-avalanche and bit-independence measurements across the round function. Cheap, and expected in any cipher submission. - [ ] **Second, independent implementation** — a from-spec Python or Rust port that reproduces the KATs. This cross-checks the cipher *and* proves the spec is complete enough to reimplement from — the real test of `DESIGN.md`. ## Phase 2 — Protocol & system rigor · weeks · solo + collab - [ ] **Cipher agility with a standardised default** — **high priority.** The `securechannel` protocol only needs *an* AEAD. Offer AES-256-GCM (or XChaCha20-Poly1305) as the default suite and AES512 as an explicit *research* suite. This makes the shipped messenger safe to use **today**, regardless of what cryptanalysis finds, and moves the paper's posture from "the system rests on an unaudited cipher" to "the system is secure on standard primitives; the new cipher is a swappable, clearly-labelled research contribution." It is the single change that most de-risks a public release for real users. - [ ] **Machine-checked handshake proof** — a Tamarin or ProVerif model of the 4-message handshake against a Dolev–Yao attacker, verifying the claimed properties (mutual authentication, forward secrecy, passive identity hiding, downgrade absence). An ideal scoped project for a security PhD: it either verifies or finds a real flaw — both are publishable. Model the proof on the SIGMA / KEMTLS literature the design already follows. - [ ] **KEM-combiner positioning** — the handshake feeds concatenated secrets into HKDF; argue this against the KEM-combiner literature (Giacon–Heuer–Poettering; Bindel et al.; X-Wing) instead of assuming it. - [ ] **Bitsliced constant-time core** — the biggest single implementation item: makes constant-time *structural* and removes the ~30× throughput penalty at once. Well-trodden ground (Käsper–Schwabe). Already flagged as the performance follow-up in `DESIGN.md` §5. - [ ] **Machine-readable specification** — a hacspec or Cryptol spec, enabling formal cross-checking and machine-generated test vectors. ## Phase 3 — External review & publication · months → years · community This phase is the actual security gate. **Nothing in Phases 0–2 lets the project climb past L1 on its own** — that requires people who are not us. - [ ] **ePrint preprint** — publish the spec plus the Phase 1–2 self-cryptanalysis on IACR ePrint, with the honest framing intact. Early, informal community review is worth more than polish. - [ ] **Engage symmetric-crypto specialists** — via the TU Dresden collaborators, seek introductions to symmetric-primitive groups (Bochum, Graz, Radboud, Luxembourg are the nearby centres of gravity). **L2 begins the day outside cryptographers publish findings.** - [ ] **System paper** — the verifiable-install client + untrusted relay + reproducible build, evaluated against the chat-control threat model, for a privacy/systems venue (PETS, USENIX Security). This is the stronger near-term paper and matches the collaborators' systems/privacy strengths. - [ ] **Cipher paper** — design + self-cryptanalysis + open problems, for a symmetric-crypto venue (ToSC/FSE, SAC). - [ ] **Sustained cryptanalysis → L3** — the multi-year, open process that is the only honest basis for the word "secure." Every result, including breaks, is tracked in the issue tracker and the log below. --- ## Publication strategy: two papers, not one Conflating the system and the cipher weakens both. They have different audiences, venues, and standards of proof: - **The system** (client integrity + untrusted relay + threat-model mapping) is a *privacy-engineering* contribution. It stands on standardised primitives and does not depend on AES512 at all — especially once cipher agility lands. Venue: PETS / USENIX. Reviewers: systems & privacy. - **The cipher** (AES512 / Ragnarok-512) is a *symmetric-cryptography* contribution: a design published *together with its designers' own cryptanalysis and open problems*. Venue: ToSC / SAC. Reviewers: symmetric primitives. Keeping them separate lets the system paper be strong now while the cipher earns its confidence on the slower clock it necessarily runs on. ## Open problems — how to contribute These are tracked as public issues (labels `cryptanalysis`, `open-problem`). The design is published *so that* it can be attacked; a break is a contribution, not an embarrassment, and will be credited and linked here. Concrete starting points live in [`SECURITY-ANALYSIS.md`](SECURITY-ANALYSIS.md) §7 — reduced-round distinguishers beyond the trail bounds, the XOF-schedule model, the AEAD/SIV instantiations, a machine-checked handshake model, and independent constant-time verification. Reproduce everything with `go test ./...` (MDS proof, KATs, Monte-Carlo chain, fuzz seeds); regenerate vectors for an independent implementation with `cmd/genkat`. Report via the issue tracker or the contact in [`SECURITY.md`](../SECURITY.md). ## Log Dated record of what actually shipped, so the progression is legible and the claims above stay tied to reality. - **2026-07-12** — v1 → v2 → v3 cipher hardening: proven-MDS Grøstl MixBytes layer (exhaustive 12 869-minor test), constant-time table-free S-box, SHAKE-256 key schedule, 18 rounds; committing AEAD + misuse-resistant SIV. securechannel v3: hybrid X25519 + ML-KEM-1024 handshake, KEMTLS-style PQ mutual auth, per-message ratchet. **L0 reached.** - **2026-07-12** — End-to-end WASM web messenger + untrusted relay; browser-layer hardening (strict CSP, passphrase-encrypted identity at rest, SRI). - **2026-07-14** — Single-file offline client (byte-reproducible, CSP-hash-pinned); `docs/CHAT-CONTROL.md` threat-model mapping. - **2026-07-15** — Ragnarok landing page + self-hosted relay downloads; deployed at `ragnarok.baldin.io`. Published docs audited spec-vs-code and hardened for a research audience (falsifiable claims/non-claims, an "invitation to break it" section). Fixed a self-connection bug (two same-identity tabs pairing into a chat with themselves). - **2026-07-15** — This roadmap and the claim ladder published. **L1 opened.** ## References - Daemen, Rijmen — *The Design of Rijndael* (wide-trail strategy). - Mouha, Wang, Gu, Preneel — *Differential and Linear Cryptanalysis using Mixed-Integer Linear Programming* (active-S-box bounds). - Todo — *Structural Evaluation by Generalized Integral Property* (division property). - Chen, Steinberger — *Tight Security Bounds for Key-Alternating Ciphers*. - Käsper, Schwabe — *Faster and Timing-Attack Resistant AES-GCM* (bitslicing). - Reparaz, Balasch, Verbauwhede — *dudect* (constant-time measurement). - Giacon, Heuer, Poettering — *KEM Combiners*; Bindel et al. — *Hybrid Key Encapsulation*; the X-Wing combiner. - Krawczyk — *SIGMA*; Schwabe, Stebila, Wiggers — *KEMTLS*.