8Z-Auth:
Software Unclonable Functions

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.

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.

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.

The Protocol

Three Layers

8Z Primitives Used

All four primitives already exist in the 8Z codebase — no new crypto invented:

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

Operational separation is left to the operator. Public-facing material should describe the access experience, not expose implementation-sensitive routing or hosting details.

User Experience

Daily Use

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):

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?

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.

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):

Roadmap