Every company believes their data is protected by encryption. Almost none realize their encryption still gives attackers everything they need — because the decryption key lives on the same server attackers just owned. XenSplit is not a better lock on the door. This is a safe where the combination never existed inside the building.
The same attack. Five different architectures. One outcome changes everything.
Five interactive browser demos — no server, no installation. Each runs in real time, in your browser. The attack is identical. Only the architecture differs.
All demos use standard browser mechanisms to demonstrate the patented concepts from Applications 64/075,248 and 64/094,316. Production implementations use server-side infrastructure with the same XenSplit component distribution architecture. No specialized hardware required.
Demo 1 uses no encryption. Demo 2 demonstrates XOR encryption with components distributed across browser storage locations. The server component is simulated locally - in production, this would be retrieved from a secure server while client components remain device-bound.
In a production environment, Demo 1 would require server infrastructure. For these demonstrations, Demos 2-5 implement component storage using standard browser mechanisms (localStorage, sessionStorage, and environmental factors). These implementations illustrate the XenSplit component distribution concepts from patent 64/075,248 and the environmental keying from patent 64/094,316, without requiring specialized hardware.
An attacker bypasses an access check and requests User 1002. Demo 1 stores plaintext. Demo 2 stores a XOR fragment with the key held only on the client device using XenSplit architecture.
S = D ⊕ C is XOR encryption — the primitive is intentionally simple and auditable. Shannon (1949) proved a one-time pad (XOR with a truly random key at least as long as the message) leaks zero information about the plaintext. With a 256-bit key, we gain computational security rather than information-theoretic security. The XenSplit patent claim is the method: environmental derivation, structural key separation, and mathematical role enforcement — not the XOR operation itself.
The client computes S = D ⊕ C locally and sends only S to the server. C never leaves the client device. The server stores S and never receives D or C. XenSplit means the server has no key and cannot reverse the operation.
C is stored on the client device and never transmitted after enrollment. The client requests S and computes D = S ⊕ C entirely locally. The server never sees D during retrieval and cannot perform this step itself.
Randomize D and C, watch S computed, then verify S ⊕ C recovers D exactly
XenSplit IS encryption — XOR with a client-held 256-bit key. The primitive is not the novel claim. The architectural difference from server-side AES-256 is where the key lives. When the key is on the server, the server can be compelled to decrypt. When the key structurally never exists on the server, it cannot.
| Scenario | No Encryption | Server-side AES-256 | XenSplit Architecture |
|---|---|---|---|
| Access control bypass (IDOR) | Full plaintext returned | Ciphertext returned — safe only until key is found | XOR fragment — key was never on this server |
| Server fully compromised (root) | All data exposed immediately | Key often co-located — all data exposed | Attacker finds only ciphertext — no key exists on this disk |
| Legal compulsion / subpoena | Server must produce plaintext | Server must produce decryption key | Server cannot comply — it genuinely does not hold the key |
| Key compromise | N/A — data already exposed | All historical data retroactively exposed | No server-side key to compromise — XenSplit keys are per-user and local |
| Unlimited compute attack | Irrelevant — already readable | AES-256 is computationally hard — secure today, not proven forever | Key never exists on server — no key to attack regardless of attacker’s compute power or future algorithms |
| Security foundation | None | Computational hardness (NP assumptions) | XenSplit — structural key separation and environmental derivation; 256-bit computational key security |
My research focuses on information-theoretic approaches to data security that transcend computational assumptions. With 25+ years in IT implementation and 12 years in security education, I bridge theoretical cryptography with practical deployment challenges.
Throughout my career, I've consistently addressed real-world security gaps in everyday systems. I developed commercial security assessment platforms to help small businesses identify external exposures. For enterprise environments, I created secure credential distribution systems that replaced unsafe email sharing with self-destructing delivery mechanisms. I've also built encrypted document management solutions that protected sensitive communications even at rest on local machines - implementing encrypted HTML wrappers around PDF downloads with unique per-session passwords to prevent local file exposure.
These practical solutions revealed a pattern: we can improve security around the edges, but the fundamental vulnerability remains - data can still be accessed when systems are compromised. XenSplit emerged from this insight - representing a paradigm shift from securing the perimeter to making the data itself mathematically inaccessible without proper authorization.
What makes XenSplit unique is its origin in human-AI collaboration. While working on a separate patented project, I discovered a solution that unexpectedly connected to environmental derivation principles. This breakthrough emerged through an iterative process where I could rapidly prototype and test concepts that would have been impossible to explore at this scale and speed without AI assistance. I provided the architectural vision and mathematical principles while AI handled implementation details — constantly guiding it back when implementation strayed from core insights.
My journey into security began as a tinkerer — flashing firmware on my own equipment and following others' hacks to understand how systems worked from the inside out. For years, I implemented existing techniques rather than discovering new vulnerabilities. That all changed when AI became my collaborative partner. It was the tool that finally allowed me to translate my cross-domain insights into working implementations, enabling me to move from practitioner to innovator. My ADHD-driven tendency to connect disparate patterns across domains became the key insight that traditional experts, siloed in their specialties, had missed.
XenSplit represents a shift from policy-based security to structural security grounded in mathematical principles — where protection emerges from architecture rather than enforcement.
This is not a product. This is foundational intellectual property. XenSplit defines a new category of data protection — and the window to own that category in your industry is open now.
● Post-quantum transition is forcing infrastructure redesigns across every sector
● GDPR, HIPAA, CCPA enforcement is intensifying breach liability
● Early partners get preferred positioning as XenSplit patent matures
● Architectural security is becoming a board-level priority
● Option to license upon patent grant at favorable terms
● Access to ongoing protocol improvements
● Strategic input on XenSplit protocol evolution
● First-mover advantage in your industry
Ready to own a new category of data protection
before your competitors even know it exists?
Strategic Advantage: Early partners gain preferred positioning and input on XenSplit protocol evolution. While implementation is openly documented, partnership provides legal protection and first-mover advantage as the patent matures.
Direct line to the inventor. No sales team. No NDA required for initial discussion.
Flexible partnership arrangements including option agreements, strategic collaboration, and preferred positioning as the XenSplit patent matures
Direct access to the inventor for clarification on XenSplit protocol mechanics and architectural principles during implementation
Address the $150B+ cybersecurity market with XenSplit's differentiated approach that provides architectural security beyond compliance requirements
When a component is deleted — device wiped, tab closed, environment changed — reconstruction becomes permanently impossible. No subpoena, breach, or backup recovers it. Deletion is mathematically final, not a policy decision that can be reversed under pressure.
Claim 1 — Component DistributionThe key C is generated on the client device and never transmitted after enrollment. The server holds only S. A court order, a root breach, or a rogue employee cannot produce C — it is structurally absent, not procedurally withheld.
Claim 1 — Component DistributionXenSplit operates at the data layer. Existing databases, REST APIs, and transports require no changes. AES or TLS can be layered on top without changing the core property. The novel claim is the system and method, not the XOR operation itself.
Claim 34 — Encoding Agnosticism