Security Architecture — One Step Ahead

Three Layers of Protection

Every piece of data protected by One Step Ahead passes through three distinct layers before a single fragment is produced.

1

Cryptographic Protection

AES-256-GCM encryption with a unique random key per operation. Provides both confidentiality and authenticated integrity — any tampering causes decryption to fail explicitly.

2

Threshold Distribution

Smart Split divides the encryption key across 3 fragments. Any 2 out of 3 reconstruct the key. No single fragment holds enough to decrypt alone.

3

Representation

Fragments are encoded as QR codes or binary .s32 files depending on data type and version. The representation layer does not alter the security properties.

Cryptographic Details

Every component chosen for clarity, auditability, and independent verifiability.

Seed Generation

~392 bits entropy

For every encryption operation, a cryptographically random 66-character seed is generated using an alphanumeric character set (a–z, A–Z, 0–9). This produces approximately 392 bits of entropy — substantially exceeding the 256-bit security level of AES-256-GCM. The seed is ephemeral — it never exists in full in any single output and lives in memory only for the duration of the operation.

Key Derivation

SHA-256

The AES encryption key is derived by applying SHA-256 to the full 66-character seed. This produces a fixed-size 256-bit key suitable for AES-256-GCM. SHA-256 is appropriate here because the seed is a high-entropy randomly generated value — not a user-supplied password. Password-based key derivation functions such as PBKDF2 or Argon2 are designed to compensate for low-entropy inputs and are unnecessary in this context. All 66 seed characters influence the derived key — any single character change produces a completely different key.

Encryption

AES-256-GCM

Data is encrypted using AES-256-GCM. A unique random nonce is generated for every encryption operation. The resulting output is a combined blob containing the nonce, ciphertext, and GCM authentication tag. AES-256-GCM provides both confidentiality and authenticated integrity — any tampering with the ciphertext causes decryption to fail explicitly. There are no silent failures.

Seed Split

3 × 22 characters

The 66-character seed is divided into three equal non-overlapping portions of 22 characters each — Leading (characters 1–22), Middle (23–44), and Trailing (45–66). Each fragment receives exactly two of the three portions. Any two fragments together contain all three portions, allowing full seed reconstruction and key re-derivation. The split is fully deterministic and introduces no additional randomness beyond the initial seed generation.

Input Normalisation

BIP-39 validation

Before encryption, input data is normalised to a canonical form. For cryptocurrency wallets, each BIP-39 word is validated against the full word list and stored as its corresponding index number rather than the word itself. This ensures the canonical input is language-agnostic and unambiguous. If any word fails BIP-39 validation, the operation is rejected before encryption is attempted.

Integrity Verification

Explicit for binary

For text and QR fragments, mismatched fragments produce invalid output — failure is detectable. For binary .s32 files (images and PDFs), integrity verification is performed explicitly during reconstruction. The mechanism detects partial corruption, accidental modification, and fragment mismatches. Reconstruction fails immediately and explicitly when verification does not pass.

Threat Model

What One Step Ahead is designed to protect against — and what it is not. Honest about both.

✓ Mitigated

Loss or destruction of a single device or fragment
Accidental deletion of one fragment
Unauthorised access to a single fragment
Data corruption — detected via integrity verification
Vendor lock-in — open reconstruction spec
Network interception — no network connection ever made
Cloud breach — no cloud storage used

✗ Not mitigated

Malware present at the moment of encryption
Coercion or forced disclosure of two or more fragments
Loss of all three fragments simultaneously
Physical compromise of two or more storage locations at once
Weak secrets — OSA protects how your secret is stored and distributed, not the strength of the secret itself

Privacy & Data Handling

One Step Ahead operates entirely offline and does not require or establish any internet connection at any point during operation.

No data transmitted to external servers
No third-party frameworks, SDKs, or analytics
Sensitive data never cached, logged, or persisted
All cryptographic operations performed in memory
Data discarded upon completion — nothing written without explicit user action
Only non-sensitive preferences stored locally — output type, Smart Split version, terms acceptance

Binary Fragment Format (.s32)

How images and PDF files are stored and protected.

Binary data types — images and PDFs — are stored as .s32 files. This is a proprietary binary container format used by One Step Ahead to store encrypted, split binary fragments. Each .s32 file contains the full encrypted payload and two of three seed portions required for reconstruction.

The file structure and internal content are intentionally opaque — no information about the protected data is exposed within the file itself.

Filenames follow a human-readable convention that includes a short random identifier and a creation timestamp. This is a deliberate usability compromise — the filename exposes non-sensitive operational metadata only and reveals nothing about the protected content.

OPSEC Note — Filename Timestamps

Users operating under strict OPSEC requirements should be aware that a shared timestamp across fragments could assist an attacker in correlating fragments across locations. Renaming the files is fully supported — fragment matching relies exclusively on the identifier embedded within the encoded payload, not on the filename. Only the .s32 extension must be preserved.

Full Technical Disclosure

Every design decision, parameter choice, and security property is documented in the public White Paper. Read it, audit it, and build your own recovery tool from it.

Read the White Paper Download the App