8Z-Auth:
Software Unclonable Functions
A novel authentication protocol where the algorithm itself is the identity — with DCC-governed adaptive challenge-response, competing proof generators, and structural P=NP resilience through pure symmetric design
What Is 8Z-Auth?
8Z-Auth is an authentication protocol that introduces three novel concepts to the security landscape:
Software Unclonable Functions (SUFs) — the software equivalent of hardware Physical Unclonable Functions (PUFs). Where PUFs use silicon manufacturing variation as identity, SUFs use the specific implementation decisions of a codebase — PRNG constants, serialization formats, hash chain structures — as an unclonable fingerprint.
Competing proof generators — multiple algorithmic generators (XorShift chain, compression output, TSP tour hash) compete under MDL selection to produce the proof. Only someone with ALL generators can respond to any challenge.
DCC-governed adaptive difficulty — the protocol's internal state evolves deterministically based on authentication history. Successful use increases coupling (faster next time). Failures decrease coupling (harder next time). Not ML-based — deterministic and protocol-internal.
Your code is your fingerprint. The algorithm itself is the key.
The Problem
Standard authentication uses one of three factors: something you know (password), something you have (device/token), or something you are (biometrics). All use generic, published algorithms — AES, SHA, ECDSA — shared by millions. Your 2FA app uses the same HMAC-SHA1 as everyone else's.
For personal security — protecting tools, files, or applications that only you use — this is over-engineered in some ways (server infrastructure, key management) and under-engineered in others (the algorithm provides zero identity signal).
Kerckhoffs's Blind Spot
Kerckhoffs's Principle (1883) states: a cryptographic system should be secure even if the attacker knows everything about the system except the key. This is correct — for algorithms used by billions. SHA-256's security doesn't depend on the algorithm being secret.
Kerckhoffs's is a population-level rule. At N=1 — where the algorithm exists on one machine, shaped by one mind over decades — the algorithm IS the secret. The search space isn't a key space. It's the space of all possible algorithm implementations. Nobody in security questions this because Kerckhoffs's is axiomatic — the first thing they learn.
8Z-Auth asks: where's the evidence this applies when N=1?
The Core Insight
Authentication IS Compression
"Prove you're Bojan" is equivalent to "produce the shortest program that generates the correct response to this challenge." That's the Minimum Description Length principle — identity as the minimum description that reproduces the data.
Your 8Z code IS the minimum description of "you" in authentication context. Nobody else can compress the challenge into the correct response because nobody else has the generator.
Software Unclonable Functions
Hardware PUFs exploit manufacturing variation — each chip is unique because you can't perfectly control the fabrication process. Over 1 billion PUF-secured devices are deployed worldwide.
Software PUFs exploit implementation variation — the specific decisions a programmer made. Your XorShift64Star uses constants (12, 25, 27) and multiplier (2685821657736338717). Your params_to_bytes uses a specific length-prefixed sorted-key serialization. Your derive_seed_u64 chains SHA3-256 of concatenated domains. Nobody else on Earth has this exact pipeline.
Traditional auth uses: something you know, something you have, something you are.
8Z-Auth adds: something you built. Your algorithmic pipeline is a fourth authentication factor — not a key, not a device, not a biometric, but an implementation fingerprint.
The Protocol
Three Layers
A strong passphrase that seeds the key derivation. Standard factor. 20+ characters of something only you'd know.
The 8Z transformation pipeline: params_to_bytes() → derive_seed_u64() → XorShift64Star → DCCSMeter. The specific constants, byte layouts, hash chains, and iteration logic. This is your algorithmic fingerprint.
After each successful auth, coupling u increases (exploit — faster). After failures or long gaps, u decreases (explore — harder). The PBKDF2 iteration count becomes 100000 + round((1-u) × 500000). You barely notice. An attacker is progressively throttled.
8Z Primitives Used
All four primitives already exist in the 8Z codebase — no new crypto invented:
| Primitive | Role in 8Z-Auth | Origin |
|---|---|---|
| params_to_bytes() | Deterministic serialization — the "dialect" | 8Z-RP TSP Solver |
| derive_seed_u64() | Three-input seed derivation via SHA3-256 | 8Z-RP TSP Solver |
| XorShift64Star | PRNG with specific bit-shift constants | 8Z-RP TSP Solver |
| DCCSMeter | Adaptive coupling controller for difficulty | Digital Claustrum (1995 → 2024) |
Protocol Flow
CHALLENGE: nonce N = SHA3(date_YYYYMMDD + blob_header_salt)
DERIVE: seed = derive_seed_u64(SHA3(passphrase), "8Z_AUTH",
params_to_bytes({"nonce": N, "day": YYYYMMDD}))
ITERATE: rng = XorShift64Star(seed)
run rng.next_u64() exactly K times
where K = 64 + (day_of_month × 7) × DCC_factor(u)
RESPONSE: key_material = SHA3(rng.state as 8 bytes)
DECRYPT: AES-256-GCM(blob, PBKDF2(key_material, salt, iterations))
The response is used as decryption key material, not compared against a stored hash. Wrong response → garbage bytes → nothing renders. No oracle, no feedback, no "try again" message. Just silence or success.
Architecture
Five Walls of Defense
Three obscurity walls (weak individually, strong in combination — all three must fail simultaneously) plus two mathematically hard walls. An attacker who defeats obscurity still faces AES-256-GCM encryption plus a custom algorithmic pipeline they can't replicate.
Three Components
bd_vault_encrypt.py your machine only
Takes HTML trader + passphrase. Generates daily challenge seed from date. Derives AES key from 8Z pipeline. Outputs encrypted blob with unencrypted header (challenge display data only — never the answer).
Encrypted Blob hosted anywhere
Looks like random bytes. Anyone can download it. Useless without the decoder AND the passphrase AND the correct algorithmic pipeline. Can be on GitHub Pages, any static host, or a random URL.
bd_vault_decoder.html separate host or local
You open it. Enter blob URL. It fetches the blob, shows challenge. You enter passphrase. It runs the 8Z pipeline, derives key, attempts AES decryption. Success → trader renders in iframe. Failure → nothing.
Zero connection between blob host and decoder host. The association exists only in one mind. Two URLs on two different services, with no link, no reference, no shared domain.
User Experience
Daily Use
Step 1: Open decoder page (bookmark, local file, whatever)
Step 2: Blob URL auto-remembered, or paste it
Step 3: Type your passphrase
Step 4: Your trader appears. Trade.
Total time added: ~5 seconds.
If the passphrase is wrong: the iframe shows nothing. No error message. No "incorrect password." No feedback whatsoever. Just an empty frame. This is deliberate — no oracle for an attacker to probe.
DCC Adaptive Layer
The decoder maintains a small local counter (or derives state from usage patterns):
| Scenario | Coupling u | PBKDF2 Iterations | Effect |
|---|---|---|---|
| 10 days daily use | u → 0.9 | ~150K | Fast unlock (<1s) |
| Normal daily use | u = 0.5 | ~350K | Standard (~2s) |
| 1 week gap | u → 0.2 | ~500K | Slightly slower (~4s) |
| Multiple wrong attempts | u → 0.0 | ~600K | Slow (~6s) — brute-force wall |
You'd never notice the difference between 1s and 2s. An attacker trying thousands of passphrases faces exponentially increasing computation per attempt.
Competing Generators (Optional Layer)
Instead of always using the same key derivation, the challenge rotates through generator types based on day_of_year % num_generators:
Generator A: XorShift64Star chain (K iterations of PRNG)
Generator B: Compressed size of a specific byte sequence via 8Z codec logic
Generator C: Tour hash of a mini-TSP instance (10 cities, your solver)
Your decoder has all generators. An attacker who reverse-engineers one still can't handle the others. This is MDL selection applied to proof generation — which generator produces the "shortest proof" for today's parameters.
Software PUF Factory
From Personal Tool to Universal Product
8Z-Auth works for one person. But what if anyone could have their own?
A Software PUF Factory is a program that generates unique encoder/decoder pairs by randomizing the algorithm internals. The architecture is public (like a PUF chip design). Each instance is unique (like each manufactured chip). The generation seed is used once and discarded — exactly like manufacturing variation.
You run the factory program. It picks random:
• XorShift constants (bit-shift amounts, multiplier)
• params_to_bytes field ordering and type markers
• Hash chain depth and intermediate mixing steps
• DCC threshold values and iteration formula
• Generator selection schedule
It outputs two files: my_vault_encrypt + my_vault_decrypt.html. The factory program can be open source. Kerckhoffs's Principle is satisfied at the population level (everyone knows the architecture), but each instance is unclonable because the specific random choices are used once during generation and never stored.
Hardware PUF: Public chip design + unique manufacturing variation = unclonable identity
Software PUF Factory: Public factory program + unique random generation seed = unclonable instance
Both satisfy Kerckhoffs's at the population level while providing per-instance uniqueness.
Prior Art & Novelty
Extensive research across NIST standards, RFCs (RFC 6287 OCRA, RFC 1994 CHAP), academic papers, security forums, and open-source projects (March 2026):
| Existing Concept | What It Does | What 8Z-Auth Adds |
|---|---|---|
| Challenge-Response | Standard crypto (HMAC-SHA1) with shared secrets | Custom algorithmic pipeline as identity factor |
| Hardware PUFs | Manufacturing variation as unclonable identity | Implementation variation as unclonable identity (Software PUF) |
| Proof of Work | Computational puzzles as access gates | Computation as identity (not just cost) |
| Adaptive MFA | ML risk scoring adjusts auth requirements | Deterministic DCC governance (protocol-internal, not ML) |
| SyncSeed (GitHub) | PRNG-based C-R with seed mutation | Competing generators + MDL selection + DCC adaptation |
| Password-based Encryption | Derive key from password | Key derived from password + custom algorithmic pipeline + time |
Software Unclonable Functions — nobody has proposed this concept
Competing proof generators under adaptive governance — no prior art
Authentication as compression (MDL identity) — no prior formulation
DCC-governed adaptive difficulty in auth protocols — no prior art
The intersection of PUF + challenge-response + proof-of-work + MDL identity + DCC governance is unoccupied.
P=NP Resilience
A constructive proof of P=NP would be the largest earthquake in computer science history. Every public-key cryptosystem — RSA, elliptic curves, Diffie-Hellman — depends on problems (factoring, discrete logarithm) being hard. If P=NP, they have polynomial-time solutions. TLS/SSL collapses. Bitcoin signatures break. OAuth, FIDO2, digital certificates — all gone.
All public-key cryptography. Any system that relies on asymmetric key exchange, digital signatures, or public-key certificates is vulnerable. This includes most of the internet: HTTPS, VPNs, banking, cryptocurrency, email encryption.
Most authentication systems. OAuth needs a server over TLS. FIDO2 uses public-key pairs. TOTP apps depend on shared secrets established over TLS. Even if individual links are symmetric, the chain includes asymmetric crypto somewhere.
Symmetric cryptography. AES-256 requires brute-forcing 2256 keys. That's exhaustive search, not an NP problem. P=NP doesn't give you a shortcut to try fewer keys.
PBKDF2 with high iterations. 10 million sequential hash computations per guess. P=NP doesn't make sequential computation faster.
8Z-Auth. The entire pipeline is symmetric: SHA-256 → XorShift64Star → SHA-256 → PBKDF2 → AES-256-GCM. No RSA, no elliptic curves, no key exchange, no digital signatures. Nothing for P=NP to attack.
Why This Isn't Obvious
Most authentication systems are not purely symmetric. They depend on chains that include public-key crypto for key exchange, session establishment, or identity verification. Even if AES itself survives, the protocol surrounding it breaks. A system that uses AES-256 but establishes the key over TLS is still vulnerable — the key exchange collapses.
8Z-Auth has no chain. No key exchange. No server handshake. No TLS dependency. No public-key component. Passphrase → local symmetric derivation → local symmetric decryption. End to end. The key never travels over a network. It's derived locally from a passphrase that never leaves your keyboard.
Accidental Resilience Through Simplicity
This wasn't a design goal. The requirement was "no server, runs locally, keep it simple." That constraint forced a purely symmetric architecture, which happens to be the one branch of cryptography that survives P=NP, quantum computing, and every other theoretical threat currently known.
Serverless single-user architecture implies P=NP resilience as a structural property. Multi-user systems need key exchange, which requires asymmetric crypto, which P=NP breaks. Single-user systems can be purely symmetric — and therefore immune. Most people don't get this for free because they need multi-user support. The 8Z-Auth use case (one person, local decryption) is precisely the case where pure symmetry is both sufficient and maximally resilient.
| System | Uses Asymmetric Crypto? | Survives P=NP? |
|---|---|---|
| HTTPS / TLS | Yes (key exchange) | No |
| OAuth 2.0 | Yes (via TLS) | No |
| FIDO2 / WebAuthn | Yes (public-key pairs) | No |
| Bitcoin / Ethereum | Yes (ECDSA signatures) | No |
| TOTP (Google Auth) | Indirect (setup via TLS) | Partially |
| Password-protected ZIP | No | Yes |
| 8Z-Auth | No — purely symmetric | Yes |
Note: NIST standardized post-quantum replacements (CRYSTALS-Kyber, Dilithium, SPHINCS+) in 2024 for systems that need asymmetric crypto. 8Z-Auth doesn't need them because it never uses asymmetric crypto in the first place.
Use Cases
Two core properties connect every use case. First: any web content can be password-protected with zero infrastructure — no server, no database, no login system, no membership plugin. Second: long-term storage where the decryption environment is unknown — a browser and JavaScript are the only dependencies, and those will exist forever.
Serverless Paywall — Sell Any Web Content
This is the largest use case by addressable market. Anyone who has ever wanted to sell or protect web content — courses, tools, albums, newsletters, portfolios, reports — currently needs a platform: Substack (10% cut), Gumroad (10%), Patreon (8-12%), WordPress membership plugins ($200/year + hosting). All require accounts, servers, and ongoing maintenance.
With 8Z Vault: encrypt → upload to any free static host → share link + passphrase with paying customers. Delete their .8zv when they stop paying. The entire "backend" is a Python script on the creator's laptop.
1. python bd_vault_encrypt.py my_course.html -p "customer_passphrase"
2. Upload .8zv to Netlify / GitHub Pages / any static host (free)
3. Create a Stripe Payment Link (no code, 2.9% per transaction)
4. Connect Stripe → Zapier → auto-email with link + passphrase
5. Done. Creator keeps 97% instead of 85-90%.
Who Needs This
Online course creators — each lesson is a .8zv, students get the passphrase when they pay. No LMS needed. Newsletter writers — free posts are normal HTML, premium posts are .8zv. Indie developers — sell HTML tools, calculators, interactive apps. Per-customer encrypted copies. Musicians — sell albums, sheet music, stems directly. Designers — premium portfolios, client deliverables, template packs. Teachers — exam materials, answer keys behind per-student passphrases. Consultants — deliver reports and analyses as encrypted HTML. Family/event content — wedding galleries, memorial pages, passphrase in the invitation.
Per-Customer Encryption — The Revocation Advantage
Pre-generate unique copies: album_001.8zv through album_100.8zv, each with a unique passphrase. Zapier picks the next unused file per sale. Each customer gets their own file. Customer stops paying? Delete their specific .8zv. No shared passphrase problem, no "my friend gave me the password" issue.
Payment Integration
Payments require trust verification — we can't escape external services entirely. But we reduce the stack to three free-tier tools:
| Platform | Creator's Cut | Infrastructure | Setup Time |
|---|---|---|---|
| Substack | 90% | Their servers, their rules | Minutes |
| Gumroad | 90% | Their servers, their rules | Minutes |
| Patreon | 88-92% | Their servers, their rules | Minutes |
| WordPress + plugin | ~97% | Hosting $10-50/mo + plugin $200/yr | Hours |
| 8Z Vault + Stripe | 97.1% | Free static host + Zapier free tier | 30 minutes |
For a creator making $100K/year in digital sales, the difference between 90% and 97% is $7,000/year back in their pocket.
Crypto Cold Storage
Current solutions all have a fatal dependency. Hardware wallets (Ledger, Trezor) have firmware, supply chain risks, and the company might not exist in 20 years. Steel seed plates (Cryptosteel) store seed phrases in plaintext — anyone who finds the plate has your crypto. Paper wallets degrade. Brain wallets get forgotten.
8Z-Auth cold storage: encrypt your seed phrase or private key into a .8zv file. Store the file anywhere — USB, cloud, email to yourself, print as QR code. The encrypted blob is worthless without your passphrase + the decoder. The decoder is 5KB of self-contained HTML/JS that runs forever in any browser.
The unsolved problem in cold storage: redundancy without exposure. Store your seed in one place — lose the place, lose your crypto. Store it in five places — five chances for someone to find it. With 8Z-Auth, you can store the encrypted .8zv in unlimited locations simultaneously (USB, cloud, email, QR tattoo) because the file is AES-256 encrypted. Redundancy is free. The passphrase is the only secret, and it lives in your head.
| Solution | Survives 20 Years? | Encrypted? | Free Redundancy? | Needs Hardware? |
|---|---|---|---|---|
| Ledger / Trezor | Firmware risk | Yes | No (one device) | Yes |
| Steel Seed Plate | Yes | Plaintext | No (exposed) | No |
| Paper Wallet | Degrades | Plaintext | No (exposed) | No |
| BIP-38 Encrypted Key | Needs BIP-38 tool | Yes | Yes | No |
| Password ZIP | Needs ZIP software | Yes | Yes | No |
| 8Z Vault (.8zv) | Any browser, forever | AES-256-GCM | Unlimited copies | No |
Digital Inheritance
You die. Your crypto, passwords, important documents — locked forever. Current solutions: give your lawyer a sealed envelope (trust-based), use a service like Vault12 or Casa (company must exist), or leave written instructions (security nightmare).
8Z-Auth inheritance: encrypt everything into one .8zv file. Store the file with your lawyer, your family, your bank — anywhere, it's encrypted. Store the passphrase separately — half with your spouse, half in your safe deposit box. Or use Shamir's Secret Sharing to split the passphrase across N people where any K can reconstruct it. The file is public-safe. The passphrase is the only secret. Clean separation of storage and access.
Journalist & Activist Source Protection
Current tools: SecureDrop (requires servers), PGP (requires key exchange — broken by P=NP), Signal (requires phones, metadata leaks). All require infrastructure and leave traces.
8Z-Auth: source encrypts documents into .8zv, drops the file anywhere — public paste site, email, physical USB. Passphrase communicated via in-person meeting. No server, no key exchange, no metadata, no app to install. The file on a public paste site looks like random bytes. No protocol fingerprint. No "ENCRYPTED FILE" header that draws attention.
Medical Records Portability
You travel internationally. You have a medical condition. Current: carry paper records (losable), use a health app (company-dependent), hospital portal (internet required, country-specific).
8Z-Auth: encrypt your medical records into .8zv. Store on your phone, USB keychain, cloud. Any ER doctor anywhere in the world with a browser can decrypt it if you (or your medical bracelet) provides the passphrase. No app. No account. No internet required if the file is local. Works in any country on any device.
Serverless paywall has the largest addressable market — millions of creators, teachers, musicians, developers who need content protection without platform dependency. The product is already built and tested (the author uses it daily for live trading tools). Crypto cold storage is the fastest premium path — the $2B+ market has no browser-only, P=NP-safe competitor. Both products share the same core: bd_vault_encrypt.py + bd_vault_decoder.html.
Roadmap
bd_vault_encrypt.py (Python) + bd_vault_decoder.html (JS). AES-256-GCM + PBKDF2 + passphrase. No DCC, no competing generators. Just works.
Add adaptive difficulty. Decoder tracks auth history locally. PBKDF2 iterations scale with coupling u. Progressive brute-force resistance.
Multiple proof generators rotating by date. XorShift chain + compression output + mini-TSP. MDL selects which generator proves identity today.
Open-source factory program. Anyone generates their own unique encoder/decoder pair. Publishable paper: "8Z-Auth: Software Unclonable Functions with DCC-Governed Adaptive Challenge-Response and Structural P=NP Resilience."
Every domain is the same problem. Authentication is just compression wearing a different hat. And simplicity, pursued honestly, produces resilience that complexity never reaches.
Part of the 8Z Research Framework — MDL • DCC • Competing Generators