apse

specification

What the mechanism is, exactly, including the parts of it that are weaknesses.

1 status

The scheme described here is implemented and running on this site. Every shard issued by shards is produced by the code specified below, in your browser, and every reconstruction on attest is the real inverse of it. Nothing is simulated and nothing is uploaded.

What is not implemented is listed in section 11, and that list is longer than this one. Read it before assuming anything on this site protects you.

2 definitions

secret — an arbitrary byte string. Never transmitted, never stored, and destroyed the moment it is issued.

shard — one evaluation of a polynomial whose constant term is a byte of the secret. Indexed by a non-zero x-coordinate.

n — shards issued. k — shards required. Together, the scheme, written k of n.

quorum — any set of k or more distinct shards. There is no privileged set; all of them are equal and none of them is an administrator.

3 the field

All arithmetic is over GF(28), the finite field of 256 elements, reduced by the polynomial below. One byte is one field element, addition is XOR, and there is no carry and no overflow anywhere in the scheme.

x⁸ + x⁴ + x³ + x² + 1        0x11d

This is the AES field with the standard reduction. It is chosen so that a secret of any length maps to exactly that many independent one-byte problems, which is what makes the security argument in section 8 hold per byte rather than approximately.

4 issuing

For each byte s of the secret, independently:

  • draw k−1 coefficients c₁…cₖ₋₁ from crypto.getRandomValues
  • form f(x) = s + c₁x + c₂x² + … + cₖ₋₁xₖ₋¹ over the field
  • the i-th shard takes the byte f(i), for i = 1…n

The coefficients are redrawn for every byte. Reusing one polynomial across a whole secret would leak its structure immediately, and it is the single most common way an implementation of this scheme is quietly wrong.

for each byte s:
    coeff ← random(k-1)              fresh per byte
    for i in 1..n:
        acc ← 0
        for c in k-2 .. 0:
            acc ← acc·i ⊕ coeff[c]
        shard[i] ← acc·i ⊕ s

x = 0 is never issued as a shard, because f(0) is the secret. The decoder rejects a shard claiming x = 0 rather than handing it back.

5 convening

Given any k distinct shards, the polynomial through them is unique, and Lagrange interpolation evaluated at zero recovers the constant term, which is the secret byte.

s = ⊕ᵢ yᵢ · ∏ⱼ≠ᵢ ( xⱼ / (xᵢ ⊕ xⱼ) )      evaluated at x = 0

More than k shards is not an error and does not improve anything. The extra points lie on the same curve, and interpolation returns the same answer.

6 shard format

A shard is text. It is meant to survive being pasted into a message, read aloud badly, and written on paper.

xx-yyyy…

xx     x-coordinate, one byte, hex, 01..ff  (never 00)
yyyy   f(x) for each secret byte, in order, hex

There is no version byte, no checksum and no scheme header. A shard does not carry k, so a holder cannot tell from a shard alone how many others are needed. That is a deliberate omission and section 10 explains what it costs.

7 test vectors

Reproducible with fixed coefficients rather than real entropy, so an independent implementation can check itself against them. These are computed, not transcribed.

secret       "quorum"
             71756f72756d
scheme       3 of 5
coefficients AES-128 test key bytes, cycled

shard 1      01-84d7b72b6ea3
shard 2      02-f33ec2c45d96
shard 3      03-069c1a9d4658
shard 4      04-a1ab28135d73
shard 5      05-5409f04a46bd

x = 1,3,5    → "quorum"                    quorum met
x = 1,3      → c57c6f707a50               wrong, and silent
not yet run

8 what a shard reveals

Nothing. Not a narrowed range, not a probability distribution, not a partial answer that gets better with more shards until the last one completes it.

The precise claim: for any set of k−1 shards and any candidate secret of the same length, there exists exactly one polynomial consistent with both. Every candidate is therefore supported by exactly the same evidence, which is none. This is information-theoretic, not computational — it does not rest on a problem being hard, and no amount of compute weakens it.

The practical consequence is unintuitive and worth stating plainly: holding k−1 shards is worth exactly as much as holding zero. Someone who has spent months collecting four of the five they need has achieved nothing measurable.

9 threat model

What the scheme defends against:

  • Any adversary holding fewer than k shards, with unlimited time and compute.
  • The loss or destruction of up to n−k shards.
  • Coercion of any individual holder, who genuinely cannot comply alone.

What it does not:

  • An adversary holding k shards. They are the quorum. The scheme cannot distinguish them from the intended one, and is not trying to.
  • Anyone present when the secret was issued or reconstructed, at which moment it exists in one place in plaintext.
  • A tampered shard. There is no authentication, so a holder who alters theirs corrupts the output without being detected. See section 10.
  • Coercion of k holders, or of one holder who kept copies of k shards, which is the failure mode that actually happens.

10 failure modes

Silent wrong answers. Reconstruction below quorum, or with a corrupted shard, does not fail. It returns a different secret, instantly and without complaint, and that output is indistinguishable from a correct one. Nothing in the scheme can flag this, because flagging it would require knowing the secret in order to compare.

No integrity. A malicious holder can present a shard that is subtly wrong and poison the reconstruction for everyone, deniably. Committing to each shard at issue time would fix this and is listed in section 11.

k is not carried. A holder with a shard and no memory of the scheme cannot learn how many more are needed except by trying, and trying is uninformative because of the failure above.

The secret is only as sealed as its shards. Eight shards pasted into the same chat thread are one shard in eight parts, and the scheme has no way to know that has happened.

11 not implemented

Everything here is honest about being absent rather than planned. No dates are given because none are known.

  • A shared register. sealed is local to one browser. Holders cannot discover each other, which means a quorum can only convene if it was already arranged out of band. This is the single missing piece that separates a working lock from a working system.
  • Verifiable sharing. No commitments, so no holder can prove their shard is the one they were issued.
  • Authenticated encryption of the secret before splitting, which would turn a silent wrong answer into a detectable one.
  • Any chain component whatsoever. Nothing here touches a wallet, asks for a signature, or reads an address. There is no connect button on this site and there is not going to be one.