Reed-Solomon erasure coding for storage: a practical primer

The core idea

Reed-Solomon (RS) codes are a family of error-correcting codes invented by Irving Reed and Gustave Solomon in 1960. The basic capability: take k data symbols and produce n = k + m total symbols, such that any k of the n symbols are sufficient to recover the original. Up to m symbols can be lost or corrupted without data loss.

In storage terms: split your file into k data chunks, generate m parity chunks, and store all n = k + m in distinct locations. Any k of them reconstructs the file.

The math, just enough

RS codes work over a finite field, typically GF(2^8) (Galois Field of 256 elements) for byte-oriented storage. Each data symbol is treated as a coefficient of a polynomial; parity symbols are evaluations of that polynomial at additional points. The mathematical property that makes this work: any k distinct points on a polynomial of degree k-1 uniquely determine the polynomial.

For storage purposes, you do not need to derive this from scratch. Well-tested open-source libraries — Klaus Post's reedsolomon (Go), Jerasure (C), and others — implement the operations efficiently. SkyeConnex uses a hardened production library underneath its CloudRAID layer.

RS parameters and trade-offs

The choice of k and m drives everything:

RS(5,2) — what SkyeConnex uses

5 data + 2 parity = 7 total shards per frame. Tolerance: lose any 2, recover fully. Storage overhead: 7/5 = 1.4×. Compared to triple-replication (3× overhead), this is more efficient. Compared to a single un-protected copy, it's 40% more storage for two-provider failure tolerance — and the security property that no single provider can read the data.

RS(10,4) — colder archive

10 data + 4 parity = 14 total shards. Lose any 4, recover. Storage overhead: 14/10 = 1.4× — same overhead, but you need 10 providers and reads pay the latency of the slowest of 10 (rather than 5). Suitable for long-term archive where read latency is acceptable.

RS(3,2) — paranoid replication-like

3 data + 2 parity = 5 total shards. Lose any 2, recover. Storage overhead: 5/3 ≈ 1.67×. Reads are faster (smaller shard sets), failure tolerance is the same as RS(5,2). The trade-off is the smaller k means each shard contains more of the original — slightly less spread.

The choice is a tuning between storage efficiency, fault tolerance, read latency, and security spread. SkyeConnex's RS(5,2) is the sweet spot for sovereign storage: minimal overhead, strong fault tolerance, security property that any one provider holds only 2/7 of any file.

Why this is different from replication

Replication: each replica is a full, independently-readable copy. If you replicate 3-way, each provider has the whole file. A breach of one provider exposes everything.

RS encoding: each shard is a fraction of the file. Mathematically, fewer than k shards reveal nothing about the original — this is a provable property of the code. A breach of one (or two, in RS(5,2)) providers exposes ciphertext fragments that cannot be combined into plaintext.

This is the cryptographic-storage property that no contractual sovereignty agreement can deliver. See it in the architecture →

RS inside vs RS across

Many storage systems use RS internally — Backblaze B2 famously uses RS(17,3) within its data centre to protect against drive failures. That gives you durability within one provider. It does not give you sovereignty across providers.

For sovereignty, the RS layer must operate across distinct legal entities in distinct jurisdictions. Otherwise the same provider can decrypt the same file, regardless of how the bytes are arranged on its disks.

Performance characteristics

On a recent CPU, RS(5,2) encoding/decoding runs at hundreds of MB/s per core. SIMD acceleration (SSE, AVX) pushes that to GB/s on modern x86_64. For ~5 MB frames, the math layer is essentially free; the bottleneck is parallel network I/O to the providers.

Reads parallel-fetch all 7 shards. As soon as any 5 succeed, the read completes — meaning your effective read latency is the latency of the 5th-fastest provider, not the 7th. This gives natural tail-latency improvement: slow providers are routed around without affecting user-perceived latency.

Engineering pitfalls

• Frame boundaries. RS has a hard per-frame plaintext cap (dependent on the implementation). SkyeConnex enforces frame size server-side at 5 MB to prevent client-side mismatches.
• Idempotent upload keys. Without them, scatter retries can produce duplicate shards.
• Per-shard integrity. RS doesn't detect deliberate corruption — combine it with per-shard SHA-256 hashes to catch bit-rot and substitution attempts.
• AAD binding. Pair frame-level AES-GCM with AAD that binds ciphertext to (file_id, frame_idx) — this prevents shard substitution at decrypt time.

What this enables, architecturally

RS erasure coding is the mathematical primitive that lets you make sovereignty a property of the data instead of a property of the contract. Sovereign cloud storage built on RS scales to enterprise volume with predictable economics — and gives you a security property no replicated topology can match.

Book a briefing if you want to see the full encrypt-encode-scatter pipeline running on your own file, live. 45 minutes.

---

Published May 15, 2026 · Written by SkyeConnex Inc. · More from the SkyeConnex blog