ARK — Structural Design & Layout (Security Architecture)
I. Core Philosophy
ARK is designed to deny attackers confirmation, enumeration, and termination of attacks.
Instead of optimizing solely for cryptographic strength, ARK prioritizes epistemic denial: attackers cannot know whether they have succeeded, how many vaults exist, or whether more data remains.
II. Identity & Login Model
Every phrase is a login.
Every login deterministically opens exactly one vault.
There are no usernames, accounts, vault registries, selectors, or failure states.
An empty vault is indistinguishable from a wrong or decoy vault.
III. Vault Model
Each vault is a fully isolated cryptographic universe.
Each vault has its own:
- Key material
- Salt
- Block structure
- Decoy behavior
- Logs
- Virus sweep history
- Phoenix and Pi cycle execution
Compromise of one vault exposes only that vault.
IV. Cryptographic Core
ARK uses AES-256-GCM as its primitive.
Application layering includes:
- Pi Cycle (3-1-4)
- Three Phoenix Loops (destroy, reseed, rebuild)
- Shifting block order
- Decoy block injection
There are no stable signatures or predictable structures.
V. Domes & Airlocks
Outer Dome:
- User interface
- Activity tracking
- Auto-lock logic
Inner Dome:
- Key silo
- Crypto engine
- Vault storage
- Zeroization routines
Airlocks enforce intake, quarantine, virus sweep, encryption, and storage sequencing.
VI. Virus Sweep (Mode E)
Virus sweep is mandatory and always-on.
It executes before encryption and blocks storage of:
- Packed high-entropy payloads
- Executable headers in non-executables
- Macro-enabled documents
- Script-based attack vectors
- Header mismatches
If flagged, encryption is refused and the event is logged.
VII. Security Levels
Normal:
- Longer auto-lock
- Minimal decoys
Strong:
- Shorter auto-lock
- Increased decoys
Paranoid:
- Aggressive auto-lock
- Maximum decoys
Security levels affect behavior, not cryptography.
VIII. Auto-Lock & Memory Safety
Auto-lock is time and activity based.
On lock, all key material and crypto context are zeroized from memory.
This limits memory-forensic exposure.
IX. User Interface Layout
Desktop:
- Single-file Python architecture
- Obsidian dark theme
- Security gauges
- No metadata leakage
Mobile:
- Flutter-based
- Identical cryptographic behavior
- Identical virus sweep enforcement
- No cloud dependency
X. Threat Model Coverage
ARK is designed to defeat:
- Device seizure
- Disk imaging
- Vault enumeration
- Brute-force confirmation
- Coercive disclosure
- Malware persistence via vault storage
ARK does not attempt to defeat live OS compromise while unlocked.
XI. Failure Modes (Honest)
Possible failures include:
- Weak user phrase (isolated vault compromise)
- Forgotten phrase (permanent loss)
- Pre-existing OS compromise
There are no silent or cascading failures.
XII. Security Score
Scale:
- 1 = Walkman
- 1000 = Military-grade
ARK Score: 950 / 1000
Remaining gap is deployment context only (HSM, kernel isolation, classified OS).
XIII. Final Status
ARK represents the maximum practical security achievable within a civilian software timeline without excessive complexity, fragility, or false guarantees.
