Nukesplit: Nuclear Facility Monitoring

Executive Summary

Nuclear facilities worldwide are monitored by international agencies (IAEA, NRC, ASN, etc.). Today, each agency receives readings independently or one agency holds the authoritative data stream. This creates a single point of failure: a compromised agency can suppress or falsify readings undetected.

Nukesplit implements multi-agency threshold verification. A sensor reading is split via XorIDA (threshold secret sharing over GF(2)) across K independent agencies so that any subset of K-1 or fewer agencies learns zero information about the original reading. Reconstruction requires cooperation of at least K agencies. Each agency independently audits the reading via SHA-256 hash. The mathematical guarantee is unconditional: no computational assumption, no quantum-resistant caveat. Information-theoretically impossible to forge or suppress.

Two functions cover the entire API: splitSensorData() shards a nuclear facility reading across configured agencies with HMAC-SHA256 integrity. reconstructSensorData() verifies HMAC on each share, applies XorIDA reconstruction, and returns the original reading. Zero configuration, zero npm dependencies, runs on any JavaScript runtime.

For radiation monitors, coolant flow sensors, temperature probes, and pressure gauges in regulated facilities: mathematical proof that sensor integrity cannot be compromised without detection by all threshold agencies.

The Challenge

Atomic facility monitoring is a compliance requirement under international treaty. The IAEA, national regulators, and operator-contracted monitors need independent cryptographic proof that readings are authentic and unaltered.

Today's Shortcomings

Single agency holds the reading. If one agency controls the data stream, readings can be suppressed, delayed, or altered. Regulatory audit trails cannot distinguish legitimate maintenance windows from intentional falsification.

Separate isolated reads. Multiple agencies read the same sensor independently but have no mechanism to validate consistency. An attacker who infiltrates one agency's infrastructure can poison that agency's copy without affecting others, but regulators won't know about the discrepancy until manual investigation.

Digital signatures alone insufficient. Ed25519 or RSA signatures prove who sent the reading, but not whether it came from the physical sensor or from a compromised data pipeline. The reading chain from sensor → converter → network → agency must be protected at every step.

No threshold guarantee. Current systems require trust in all parties being honest. If adversaries compromise even one monitoring agency, readings from that agency become untrustworthy. With threshold cryptography, an attacker must compromise K independent agencies simultaneously — exponentially harder.

Solution Overview

Nukesplit guarantees sensor reading integrity via multi-agency XorIDA splitting. No single agency can forge or suppress readings. Reconstruction requires K cooperating agencies. HMAC-SHA256 detects tampering on every share.

How It Works

1. Sensor Reading. A nuclear facility sensor (radiation, coolant, temperature, pressure) produces a binary reading: Uint8Array with timestamp, unit, sensor ID, facility ID.

2. Configuration. The operator specifies monitoring agencies (IAEA, NRC, ASN, etc.) and a reconstruction threshold (e.g., 2-of-3, requiring any 2 of 3 agencies to reconstruct).

3. Split. splitSensorData() applies XorIDA over GF(2) to shards the binary reading into N shares. Each share is individually HMAC-SHA256 protected with a random key. A SHA-256 hash of the original reading is computed for regulatory audit.

4. Distribution. Each agency receives its own share, agency metadata, index, total count, threshold, base64-encoded data, HMAC, and original reading size. No agency has enough information to reconstruct unilaterally.

5. Reconstruction. When K agencies decide to verify the reading, reconstructSensorData() validates each share's HMAC, applies XorIDA reconstruction, and returns the original reading bytes. If any share is tampered, HMAC verification fails and reconstruction is rejected.

Audit Trail

Each split result includes a SHA-256 hash of the original sensor reading. This hash is transmitted separately to regulators or archived. When agencies reconstruct and verify, they can independently compute the SHA-256 hash and confirm it matches. The hash enables audit without holding plaintext sensor data.

Real-World Use Cases

Six scenarios where nuclear facility monitoring demands multi-agency cryptographic verification.

Architecture

Three-layer design: threshold splitting, HMAC integrity, and audit hashing. Each component is cryptographically independent.

Data Flow

API Reference

Two core functions, four data types, and six error codes.

Core Functions

Data Types

Quick Start

import { splitSensorData, reconstructSensorData } from '@private.me/nukesplit';

// Create a sensor reading
const sensor = {
  sensorId: 'RAD-001',
  facilityId: 'FACILITY-ALPHA',
  sensorType: 'radiation',
  reading: new Uint8Array([/* raw bytes */]),
  timestamp: Date.now(),
  unit: 'mSv/h',
};

// Configure monitoring agencies
const config = {
  agencies: [
    { id: 'IAEA', name: 'International Atomic Energy Agency', country: 'AT' },
    { id: 'NRC', name: 'Nuclear Regulatory Commission', country: 'US' },
    { id: 'ASN', name: 'Autorite de surete nucleaire', country: 'FR' },
  ],
  threshold: 2, // 2-of-3 required to reconstruct
};

// Split the reading across agencies
const splitResult = await splitSensorData(sensor, config);
if (!splitResult.ok) {
  console.error('Split failed:', splitResult.error.message);
  return;
}

const { shares, readingHash } = splitResult.value;

// Each agency stores its share independently
shares.forEach((share) => {
  console.log(`Agency ${share.agencyId} holds share ${share.index}/${share.total}`);
});

// Later: reconstruct from threshold agencies
const thresholdShares = shares.slice(0, 2); // 2-of-3
const reconstructed = await reconstructSensorData(thresholdShares);

if (reconstructed.ok) {
  console.log('Reconstruction succeeded', reconstructed.value);
} else {
  console.log('Reconstruction failed:', reconstructed.error.message);
}

Security Model

Information-theoretic security via XorIDA + HMAC-SHA256 integrity verification + SHA-256 audit hashing. Three independent cryptographic layers.

Threat Model

Adversary goal: Forge or suppress a nuclear sensor reading undetected.

Adversary capability: Breach one or more monitoring agencies and modify their copy of a sensor share.

Defense: Any modification to a share is detected via HMAC-SHA256 verification during reconstruction. Reconstruction requires a threshold of K agencies. An adversary must compromise at least K agencies simultaneously to suppress detection.

XorIDA: Information-Theoretic Splitting

XorIDA operates over GF(2) (the binary field with modular arithmetic mod 2). The key property: any K-1 or fewer shares reveal exactly zero information about the plaintext. This is not a computational security claim. It holds regardless of computational power, including quantum computers.

Mathematically: if M is the original message and S₀, S₁, ..., S_{N-1} are the N shares, then for any K-1 shares, every possible plaintext M' is equally likely given those K-1 shares. An attacker with K-1 shares cannot distinguish the true message from random noise.

HMAC Verification

Each share includes an HMAC-SHA256 computed over the share data with a random key. Before reconstruction, every share's HMAC is verified. If any share is tampered, HMAC verification fails and reconstruction is aborted. This prevents an attacker from silently modifying a share.

HMAC is verified before reconstruction. Corrupted shares are rejected immediately, no XorIDA operation on tainted data.

SHA-256 Audit Hash

The split operation produces a SHA-256 hash of the original sensor reading. This hash is transmitted separately to regulatory authorities or archived. When agencies reconstruct the reading, they can compute the SHA-256 hash and compare. If hashes match, the reading is authentic. If hashes differ, the share set was tampered.

The audit hash enables verification without holding plaintext: regulatory auditors can verify readings by comparing hashes.

Known Limitations

No real-time tampering detection. HMAC verification occurs at reconstruction time, not during storage. A compromised agency's share may be altered without immediate detection.

Share encryption is caller's responsibility. Shares are base64-encoded but not encrypted. The caller must encrypt shares before transmitting or storing with agencies.

Threshold trust assumption. The security model assumes that fewer than K agencies can be compromised. If K or more agencies are simultaneously breached, reconstruction can be forged.

Cryptographic Dependencies

Nukesplit depends on Web Crypto API for:

• SHA-256 hashing (audit hash, RFC 2104 HMAC-SHA256)
• crypto.getRandomValues() (random HMAC keys, PKCS7 padding)
• @private.me/crypto (XorIDA splitting + HMAC + TLV)

No third-party cryptographic libraries. All operations use Web Crypto API or the audited @private.me/crypto package.

Benchmarks

Performance measurements for nuclear sensor data splitting and reconstruction on standard Node.js and browser runtimes.

Split Performance

Splitting a sensor reading across N agencies (K-of-N threshold):

Reconstruction Performance

Performance is linear in payload size. For typical sensor readings (64–256 bytes), split and reconstruct operations complete in under 0.5ms, suitable for real-time monitoring.

Scalability

Number of agencies (N). Increasing N (more shares) increases split time and HMAC count, but reconstruction time depends only on K (the threshold). For N=10, K=3, reconstruction requires only 3 HMACs and 1 XorIDA operation, independent of N.

Payload size. Split and reconstruction time scale linearly with payload. 1MB payload splits in ~15ms on modern hardware.

Threshold K. Only K agencies' shares are needed for reconstruction. Higher K increases security (requires more breaches to forge) but doesn't affect reconstruction time once K shares are available.

Deployment

Zero configuration. Works on Node.js, Deno, Cloudflare Workers, and browsers with Web Crypto API.

Installation

npm install @private.me/nukesplit

Environment Requirements

• Web Crypto API (Node.js 15.7+, Deno 1.0+, all modern browsers)
• TypeScript 5.x (ESM + CJS builds ship in same package)
• No npm dependencies at runtime

Configuration

No configuration files, environment variables, or initialization steps needed. The NukeConfig interface specifies agencies and threshold at runtime.

Architecture Patterns

Pattern 1: Centralized Split Server

A single server receives sensor readings, splits them, and distributes shares to agencies via secure channels (HTTPS, mTLS, etc.). Agencies store shares in secure vaults or HSMs. Suitable for operator-controlled facilities.

Pattern 2: Distributed Split

Each agency runs an instance of Nukesplit. The sensor transmits its reading to all agencies. Each agency independently splits the reading and verifies its own share. Reconstruction requires K agencies' voluntary participation. Suitable for multi-jurisdictional monitoring.

Pattern 3: Edge/IoT Split

The sensor itself (or a gateway) splits the reading before transmitting. Each share is routed independently to different agencies via different networks. The sensor never sends plaintext. Highest security for adversarial environments.

Limitations

Understanding the boundaries of Nukesplit's threat model and design choices.

Not Addressed by Nukesplit

Physical sensor integrity. Nukesplit assumes the sensor itself is not compromised. If a radiation monitor is hacked to report false readings, splitting won't help. Sensor validation is out of scope.

Transport security. Nukesplit doesn't encrypt shares. The caller must encrypt shares during transmission using TLS, mTLS, or IPsec to prevent interception.

Agency authentication. Nukesplit verifies the share's integrity (HMAC), not the identity of the agency holding it. The caller must authenticate agencies via separate means (OAuth, mTLS certs, etc.).

Real-time tampering alerts. Tampering is detected at reconstruction time, not immediately when a share is modified. Continuous integrity monitoring requires external systems.

Threshold breach. If K or more agencies are simultaneously compromised, the threat model is violated. Nukesplit cannot defend against that scenario.

Share Metadata Leakage

Each share includes metadata: sensor ID, facility ID, agency ID, threshold, total count, timestamp, unit. This metadata is not covered by HMAC. An adversary can see that 3 agencies are sharing a sensor reading with a 2-of-3 threshold without accessing the encrypted share data.

If metadata leakage is unacceptable, the caller must encrypt the entire SensorShare object (including metadata) before transmission.

Performance vs. Security Tradeoff

Larger N (more agencies) improves redundancy but increases split overhead. Larger K (higher threshold) increases security but requires more agencies for reconstruction. The caller must balance these via the NukeConfig.

No Key Rotation

Nukesplit generates a random HMAC key per split operation. The caller is responsible for securely generating, storing, and rotating HMAC keys. There is no built-in key rotation mechanism.

Synchronization

Reconstruction requires K agencies to provide shares simultaneously. If an agency is offline or delays share transmission, reconstruction is delayed. Caller must implement timeout and retry logic.

Error Handling

Six error codes covering configuration, splitting, integrity, and reconstruction.

const splitResult = await splitSensorData(sensor, config);

if (!splitResult.ok) {
  const error = splitResult.error;
  switch (error.code) {
    case 'INVALID_CONFIG':
      console.error('Config error:', error.message);
      break;
    case 'SPLIT_FAILED':
      console.error('Split failed:', error.message);
      break;
    default:
      console.error('Unknown error:', error);
  }
  return;
}

const reconstructResult = await reconstructSensorData(shares);

if (!reconstructResult.ok) {
  const error = reconstructResult.error;
  if (error.code === 'HMAC_FAILURE') {
    alertSecurityTeam('Sensor reading share tampered!', error);
  } else if (error.code === 'INSUFFICIENT_SHARES') {
    console.log('Need more shares to reconstruct');
  }
  return;
}

XorIDA Mathematics

XorIDA (XOR Information Dispersal Algorithm) operates over GF(2), the binary field. Every bit of the plaintext is split into N shares such that any K shares can reconstruct the plaintext, but K-1 shares reveal no information.

For a b-byte plaintext M = [m₀, m₁, ..., m_{b-1}], XorIDA generates N shares S₀, S₁, ..., S_{N-1}, each also b bytes. The shares satisfy:

S₀ ⊕ S₁ ⊕ ... ⊕ S_{K-1} = M

where ⊕ is bitwise XOR. Key properties:

• K-of-N threshold: Any K shares reconstruct M. Any K-1 shares reveal zero information.
• Information-theoretic: No computational assumption. Proof by Shannon entropy: K-1 shares are uniformly distributed regardless of M.
• Fast: XOR operations are constant-time on hardware. No expensive modular arithmetic.
• Quantum-proof: Shor's and Grover's algorithms do not apply to information-theoretic security.

Implementation in @private.me/crypto uses byte-level XOR with random seed generation. For details, see the XorIDA conceptual whitepaper.

Audit Hash Strategy

The split operation produces a SHA-256 hash of the original sensor reading. This hash serves as a regulatory audit trail.

After K agencies reconstruct the reading, they independently compute the SHA-256 hash and compare it with the audit hash from the split result. If hashes match, the reconstruction is verified to be authentic. If hashes differ, the shares were tampered.

The audit hash is suitable for public transmission to regulators. Regulators can verify that a reading has not been modified since split time without needing plaintext access.