Onera Docs
E2EE Architecture

Key Sharding System

3-share XOR-based key sharding requiring compromise of multiple independent systems

Key Sharding System

Onera implements a 3-share XOR-based key sharding system, requiring compromise of multiple independent systems to reconstruct the master key.

Sharding Architecture

Share Generation

function splitMasterKey(masterKey: Uint8Array): Shares {
  // Generate two random shares
  const deviceShare = randombytes_buf(32);
  const authShare = randombytes_buf(32);

  // Calculate third share such that XOR equals master key
  const recoveryShare = new Uint8Array(32);
  for (let i = 0; i < 32; i++) {
    recoveryShare[i] = masterKey[i] ^ deviceShare[i] ^ authShare[i];
  }

  return { deviceShare, authShare, recoveryShare };
}

Share Storage

ShareStorage LocationProtection
Device ShareBrowser localStorageEncrypted with device-specific key derived from: BLAKE2b(deviceId + fingerprint + serverDeviceSecret)
Auth ShareServer databasePlaintext, protected by Clerk authentication
Recovery ShareServer databaseEncrypted with user's recovery key

Device Share Protection

The device share is encrypted with a key derived from multiple sources:

Security: Even with full localStorage access (XSS), an attacker cannot decrypt the device share without the server-side device secret.

Attack Surface Analysis

Components CompromisedCan Reconstruct?Notes
Server onlyNoHas auth share + encrypted recovery share, missing device share
Device onlyNoHas encrypted device share, missing auth share
Server + DeviceStill NoRecovery share encrypted; needs recovery key
Server + Device + Recovery PhraseYesFull compromise allows reconstruction

Why Not Shamir Secret Sharing?

XOR-based splitting was chosen over Shamir Secret Sharing because:

PropertyXOR (Onera)Shamir
ThresholdAll shares requiredk-of-n configurable
ImplementationTrivialPolynomial arithmetic
Error detectionNone built-inThreshold provides redundancy
Attack surfaceSingle equationMore complex reconstruction
Audit simplicityTrivial verificationRequires crypto expertise

Rationale

  1. Simpler implementation: Less room for cryptographic errors
  2. No threshold ambiguity: Requires ALL shares (no 2-of-3 weakness)
  3. Performance: Single XOR vs polynomial evaluation
  4. Auditability: Trivial to verify correctness

The tradeoff is losing k-of-n flexibility, but Onera's design intentionally requires all three systems for reconstruction.

On this page