Skip to content

Scloud+

Unstructured-LWE KEM · ePrint 2024/1306 · FO-transformed IND-CCA2

Run a real Scloud+ key exchange in your browser — KeyGen, Encaps and Decaps over unstructured LWE with ternary secrets, BW₃₂ Barnes-Wall lattice coding, and a genuine Fujisaki-Okamoto re-encryption check.

New here? Here's the path

The sections are ordered easiest → deepest. You don't need any math background to start.

  1. The Big Picture — plain-English idea, no math.
  2. Guided Walkthrough — click through one full key exchange step by step.
  3. Core exhibits — LWE, ternary secrets, BW₃₂, keygen, the FO transform.
  4. Compare & reflect — sizes, performance, and how much it's been reviewed.

Reality Check

What This Demo Is

  • A faithful-but-simplified TypeScript implementation of the ePrint 2024/1306 ideas
  • Real SHAKE-256, SHA3-256 and SHA3-512 running in your browser (pure Keccak)
  • A genuine KEM round-trip: KeyGen → Encaps → Decaps with a real FO re-encryption check and implicit rejection
  • BW₃₂-style lattice coding with measurable error-correction radius

What This Demo Is Not

  • Not constant-time — JavaScript cannot guarantee timing-safe execution
  • Not audited or suitable for production key exchange
  • Not a substitute for a vetted C/Rust implementation
  • Not endorsed by the S-Cloud+ authors or any standards body

What the Textbook Doesn't Show

Standard LWE-KEM treatments stop at "add noise, hope it rounds away." S-Cloud+ takes a different path: Barnes-Wall BW₃₂ lattice coding provides structured error correction, so instead of each message bit having to survive on its own, a whole 5-bit chunk is carried by a 32-dimensional lattice point and the decoder corrects anything inside the packing radius of BW₃₂. That extra margin is what lets the authors shrink the modulus and the matrix dimensions while holding the security level, and it is where the size win comes from.

How big is the win? Take it from the paper's own claim rather than from a round number: Scloud+ reports a public key roughly 0.71–0.87× and a ciphertext roughly 0.56–0.78× the corresponding FrodoKEM sizes, at comparable security and without relying on algebraic ring structure like ML-KEM. An earlier version of this page said BW₃₂ "doubles the tolerable noise" compared with simple rounding; that factor is not stated anywhere in the paper and has been dropped rather than left standing as an unsourced number.