Skip to content

CONCEPT.md

Latest commit

 

History

History
103 lines (71 loc) · 4.86 KB

CONCEPT.md

File metadata and controls

103 lines (71 loc) · 4.86 KB

MEDINA — Multi-layered Encrypted Deterministic Interlocked Nested Architecture

Defense-in-Depth Symmetric Encryption Construction

Core Thesis

MEDINA is a symmetric encryption construction that combines two entangled secrets — a master key and a path key — into a defense-in-depth architecture. It uses proven primitives (AES-256, SHA3-256, HKDF) in a novel composition: the two keys are cryptographically entangled so neither can be attacked independently, layers enforce sequential decryption, and HMAC provides authentication.

What MEDINA is: An architectural contribution — a new way of composing existing primitives. What MEDINA is NOT: A new cryptographic primitive or a replacement for NIST post-quantum standards.

Pillar 1: Matryoshka Chains (Sequential Key Dependencies)

Concept: Encryption is applied in sequential, dependent layers — like nested Russian dolls. Each layer's decryption key is derived from the previous layer's key material via HKDF.

Properties:

  • Layer count is configurable (8 to 1024+ layers)
  • Each layer uses a key derived from: K_n = KDF(K_{n-1} || salt_n || context_n)
  • No layer can be skipped or pre-computed
  • The master key is entangled with the path key via HKDF before layer derivation begins — neither secret alone is sufficient

Note on quantum resistance: AES-256 already provides 128-bit post-quantum security against Grover's algorithm. Matryoshka chains add sequential dependency but do not fundamentally change the quantum security margin. The value is defense in depth, not a new quantum defense.

Pillar 2: Blind Souk Routing (Blind Path Verification)

Concept: The path key is a binary sequence that routes through a SHA3-256 hash graph. At each node, choose 0 or 1. The resulting final state derives an AES key used to wrap the Matryoshka output.

Properties:

  • Path key is a binary string: 01101001... (length = number of decision points)
  • Each node transition: state = SHA3-256(state || direction_bit || step_salt)
  • No intermediate verification — wrong paths fail silently at the authentication layer (HMAC)
  • No oracle feedback at any point — verification requires completing the entire decryption pipeline
  • Node transitions are one-way functions (cannot reverse from a node to determine the incoming path)

V2 improvement: The original V1 design stored a destination_hash in the ciphertext, which inadvertently provided an oracle for Grover's algorithm. V2 removes this entirely — path verification now relies on HMAC authentication at the final stage.

Key Entanglement (V2)

The master key and path key are cryptographically entangled before any encryption begins:

combined_key = HKDF(master_key, salt=SHA3-256(path_key), info=b"MEDINA-COMBINED")

This means:

  • Cracking the path key alone yields nothing — you still need the master key to derive combined_key
  • Cracking the master key alone yields nothing — you still need the path key for both combined_key derivation and Blind Souk unwrapping
  • The effective key space is multiplicative, not additive

HMAC Authentication (V2)

All MEDINA V2 output includes a 32-byte HMAC-SHA256 tag:

auth_key = HKDF(master_key, salt=b"MEDINA-AUTH", info=b"authentication")
tag = HMAC-SHA256(auth_key, header + encrypted_data)
  • Verified before any decryption work (fail-fast)
  • Constant-time comparison prevents timing attacks
  • Catches tampering, wrong keys, and wrong paths

Honest Assessment

Claim Status
Novel cryptographic primitive No. Uses AES-256, SHA3-256, HKDF — all existing, proven primitives
Novel construction Yes. Entangled two-factor symmetric encryption with sequential dependencies
Post-quantum secure Yes, but so is AES-256 alone (128-bit post-quantum via Grover's)
Replaces NIST PQC (Kyber/Dilithium) No. Those solve asymmetric crypto (key exchange, signatures). MEDINA is symmetric.
Defense in depth Yes. Two independent secrets, entangled keys, sequential layers, HMAC authentication
Peer-reviewed No. Not yet.
Oracle-free (V2) Yes. V1 had a destination_hash oracle. V2 removed it.

Application Areas

  • Two-factor file encryption: Master key + path key as independent secrets
  • Defense-in-depth layer: Wrap existing encrypted data in a second independent secret
  • High-value data protection: Where the overhead of sequential layers is acceptable for the added depth
  • Secret key storage: Wrap sensitive key material in a second independent layer before archival

Version History

  • V1: Matryoshka + Blind Souk with destination_hash oracle (flawed — oracle enabled Grover's)
  • V2: Entangled pillars + HMAC authentication + oracle removed. Current version.

Status

  • V2 implementation: complete
  • Formal security proof: pending
  • Peer review: pending
  • Paper: pending