KrakenCrypt Core Logo

Zero-Trust Database Encryption

Standard database encryption only needs one thing to fail: the master key. KrakenCrypt ties encryption directly to your server's hardware too, so a stolen database and a leaked key still won't open anywhere else.

Reading level:
Threat Model

What This Actually Protects You From

Not abstract security claims. Specific attack scenarios.

Identity Theft Protection

Eliminates the danger of mass data leaks. If your database is compromised or stolen, all customer records remain scrambled and completely useless to attackers.

Compliance-Ready Encryption

Many data protection laws (like GDPR in Europe and PCI-DSS for card payments) require that stored customer data be unreadable if it's ever leaked. KrakenCrypt handles that encryption requirement. The rest of your compliance program (who's allowed to see keys, how often they rotate, logging who accessed what) is still up to you.

Addresses the encryption-at-rest requirements behind PCI-DSS Requirement 3 and GDPR Article 32 (rendering stored PANs and personal data unreadable) without structural code edits. PCI-DSS also requires organizational controls around key management, such as dual control, split knowledge, documented rotation intervals, and access logging, and those remain your responsibility. KrakenCrypt handles the cryptography, not your compliance program.

Zero Insider Exposure

Even people who work at your company and can log into the database directly, like IT staff or database admins, still can't see real credit card numbers, emails, or personal details. Only the application can unlock them, and only on the right server.

Prevents sysadmins, database managers, or compromised server scripts from accessing plaintext credit cards, emails, or personal user logs.

Host-Bound, Even While Running

Tools like BitLocker only protect a powered-off drive from being physically removed and read elsewhere, which barely matters for a server sitting in a datacenter. The real risk is a stolen database backup or leaked credentials pulling data out over the network while the server is live and unlocked, and that's exactly when KrakenCrypt still holds: the stolen data still won't open on different hardware. It doesn't protect against someone who already has full control of the live server itself; at that point they could just ask it to decrypt directly.

Disk-level protections like BitLocker or TPM-sealed keys only guard against a powered-off drive being physically removed, a threat model with little relevance to server infrastructure. Once a volume is mounted, that protection ends: everything on disk is plaintext to any process with access, including malware or a remote exploit. KrakenCrypt's hardware binding is checked on every decrypt call, not just at boot, so data exfiltrated off-host, a stolen database dump, a leaked backup, intercepted network traffic, still won't decrypt on different infrastructure. It does not defend against an attacker with full RCE or root on the live host itself; at that point the legitimate decrypt path is reachable to them too, the same limitation every encryption-at-rest tool shares.

Live Interactive Failsafe

Cryptographic Defense Playground

Don't take our word for it. Read data encrypted on this server from a different one. Steal a password token, watch it go stale in storage the moment it rotates. Try to break it, right here in your browser. Free 30-day trials on your own infrastructure are opening soon for partners who want to go further than that.

Full Console Needs A Bigger Screen

The live console below (multi-field forms, a real database table, password rotation controls) needs more room to work with than a phone screen gives it. View this page on a tablet or desktop for the full hands-on demo.

Encrypt & Decrypt Personal Data 2-Way PII Field Encryption

LIVE DEMOLIVE MEMORY CIPHER

Type any sensitive value, then flip the host toggle to see whether it's still readable elsewhere.

Awaiting execution...
Awaiting execution...

Locked To This Server Host Signature Binding

STOLEN DATA FAILSAFEEXFILTRATION FAILSAFE
This Server's Unique ID:Host Signature: 51ae153bd57db57fb17abb3bbec31c1e...
User ID Email Field Phone Field Credit Card Field Action
#1 F-kzXeUVki-W81lCtp... v5OYd-dBQ_48owAbOi... z8STfMiGEUdYoLrvzc...
#2 D8azlptI9cn5yTsneh... MbCkv1K5bt2OUf1QDM... 6yxlHT9gh5rSMZWb8s...
#3 wJad4-NOWiRdpMOAJv... 2j6XpYUVxAbKoU4-0H... TQ0qqDeZ1cb_BiSgKe...
Awaiting action...
11Duoquadragintillion

Unique possible tokens for one password on one machine, drawn from four independent random values instead of three. That's over 1029 times bigger than a googol, and comfortably beyond the number of atoms in the observable universe. Four independently randomized components (the Argon2id salt, the AES-256-GCM IV, a per-call key-derivation salt, and internal padding) combine into a keyspace comfortably north of 10129 per password, per machine.

Passwords That Protect Themselves Password Hash Vault & Automatic Token Rotation

AUTO-REFRESHSALT / IV AUTO-ROTATION

Every successful user login triggers automatic salt/IV/key re-encryption. Take a snapshot of the live token as if you'd stolen it, then watch it go stale the moment the real user logs in again.

Select an account above...
Select account and click simulate...
Select account and click simulate...

PII Reads That Protect Themselves PII Token Rotation On Read ($newToken)

AUTO-REFRESHDECRYPT-TRIGGERED ROTATION

Every successful read of a stored field can also rotate it to a fresh salt/IV, the same idea as password rotation above but triggered by a decrypt instead of a login. Snapshot a live PII token as if you'd stolen it, then read the field and watch the stolen copy go stale.

Select an account above...
Select account and click read...
Select account and click read...
System Specs & Integration

Architectural Blueprint & API Reference

How the native C extension works under the hood, and what it takes to integrate it in production.

Tied To This ServerHost Signature Binding

Every encryption key is generated using a unique ID for this exact server. If someone steals your database files, they still can't read anything on a different machine. Every time that data gets read, it can also come back freshly re-encrypted, the same idea as passwords changing themselves, so a stolen old copy goes stale over time too.

Encryption keys are derived via HKDF-SHA512 bound to an OS-instance identifier unique to each host (/etc/machine-id on Linux, MachineGuid on Windows). Exfiltrated database dumps remain cryptographically unreadable on unauthorized machines. Every successful krakencrypt_decrypt_data() call can also return the plaintext re-encrypted under a fresh salt/IV via the optional $newToken parameter, the same rotation-on-use pattern as password verification.

Nothing Left Behind In MemoryZero-RAM Memory Sanitization

Encryption keys only exist in memory for a split second while they're being used, then they're wiped clean. Even a snapshot of the server's memory would find nothing sensitive left to take.

Internal C buffers are pinned in physical RAM for the duration of use, then securely wiped immediately after the cryptographic stack pops. Plaintext key material never persists in RAM or swap, mitigating cold-boot and process dump attacks.

Passwords Change ThemselvesSalt, IV & Key Auto-Rotation

Every time someone logs in successfully, their stored password gets replaced with a brand new scrambled version, sealed with a fresh one-time lock. The real password never changes. Only how it's stored does, so a stolen copy of the old one stops being useful.

Every successful user authentication triggers automatic salt/IV re-encryption under a freshly derived, single-use AES-256 key. The stored token evolves to a fresh value on every login, while the underlying credential stays verified throughout.

Fast Enough To Not NoticeNative C Core Speed

The actual encryption work happens in compiled, low-level code instead of a slower scripting language, so it adds virtually no delay to your app. You can see the real speed live in the timing badge above.

AES-256-GCM and Argon2id run once, in native compiled C. The PHP extension calls directly into that core today, and every planned language binding is designed to do the same, so none of them will carry interpreted-language crypto overhead. Typical end-to-end request time on this PHP demo is under 0.1ms, visible live in the timing badge above.

Graceful Hardware Migration

Moving to new hardware doesn't mean starting over. Passwords keep validating against the original hardware during a transition window and automatically re-bind to the new hardware the next time each user logs in, with no bulk re-encryption and no locked-out accounts. Database fields (emails, cards, phone numbers) aren't rotated automatically, since each one is tied to the exact hardware that wrote it. Migrating those requires a deliberate one-time decrypt-and-re-encrypt pass on the new server, the same as migrating any other encryption key.

Works Behind A Load Balancer, TooPrimary/Relay Deployment For Horizontal Scaling

Works even when your app runs across multiple servers behind a load balancer. The extra machines never touch your real encryption keys or hardware identity; they relay to the one server that does, with nothing to change in your application code.

Supports a primary/relay deployment model for horizontally-scaled environments. The primary remains the only machine that ever derives keys from real hardware state; other servers simply forward requests to it over an authenticated, TLS-encrypted connection, typically on a private network never exposed to the public internet. Zero code changes at the call site, and the hardware-binding guarantee above holds exactly as it does on a single server.

LIVE SECURITY PIPELINE VISUALIZER

1

Input & Validation

Accepts the raw input in secure transient memory and validates it before any cryptographic work begins.

-
Stage 1

INPUT & VALIDATION

HOW IT WORKSSECURITY MECHANICS (HOW IT WORKS)

Accepts the input bytes directly from the application request and validates size limits before any cryptographic work begins, in isolated transient memory.

WHY IT'S SAFEMITIGATION VALUE (WHY IT'S SECURE)

Ensures the input stream complies with boundaries and flags abnormal inputs immediately, before they ever reach the cryptographic layer.

2

Memory-Hard Hardening

Strengthened via a salted, memory-hard hash (Argon2id) combined with a server-side secret, making brute-force economically infeasible even on GPU/ASIC hardware.

-
3

Authenticated Envelope & Cleanup

Sealed inside an authenticated AES-256-GCM envelope. All transient key material is wiped from RAM immediately after.

CLEARED

DEVELOPER INTEGRATION CODE

KrakenCrypt ships today as a native PHP extension. Bindings for other major server-side languages are in active development. Select a language below to see what the integration will look like:

1-WAY PASSWORD PROTECTION

The PHP extension registers native global functions to handle secure password hashing (Argon2id + HMAC-SHA3-512 + AES-256-GCM) and verification, with zero additional key setup required:

// 1-Way Encrypting a password
$token = krakencrypt_encrypt("user_password123");

// 1-Way Verifying -- on success, $newHash comes back with a freshly
// rotated token; save it back over the old one in storage
$newHash = null;
$is_valid = krakencrypt_verify("user_password123", $token, null, null, "", $newHash);

2-WAY PII ENCRYPTION

Context-bound functions automatically derive sub-keys using the host machine's OS-instance fingerprint to encrypt credit cards, phone numbers, and email addresses:

// 2-Way Encrypting customer data (bound to server GUID context)
$ciphertext = krakencrypt_encrypt_data("customer_email@domain.com");

// 2-Way Decrypting -- on success, $newToken comes back with a freshly
// rotated ciphertext; save it back over the old one in storage
$newToken = null;
$plaintext = krakencrypt_decrypt_data($ciphertext, null, "", $newToken);

Export Pre-Encrypted SQL Test Dump

This isn't sample data. It's the real, host-bound ciphertext from everything you just tested. Take it to a different machine and try to crack it. If you get further than "still encrypted," email us, we want to know.

Download SQL Dump (.sql)
Partner Program

Why Partner With Us?

Built for firms whose whole business is not taking vendor claims on faith: a fix you can attach to work you're already doing, verified on your own infrastructure before you ever put your name behind it.

Close The Loop On Your Own Findings

When your own audit or pentest turns up weak encryption at rest, you already have the fix to propose in the same conversation, not a separate sales cycle six months later. No new pipeline to build, just a stronger answer to a problem you were already going to flag.

Verify It, Don't Take Our Word For It

Before you're asked to put your own name behind reselling this, break it yourself. The 30-day trial runs on your own real infrastructure, and the playground above lets your engineers try to read stolen data and watch a stolen password token go stale after rotation, right now. We'd rather you find the edges yourself than trust a sales pitch.

A Capability Your Competitors Don't Have

Anyone can write an audit report. Fewer firms can hand a client a hardware-bound fix that follows immediately after. It's a differentiator in your own pitch, not just another line item you happen to resell.

No New Business Unit Required

Your own partner dashboard issues licenses the moment a deal closes; we never contact your client, bill them, or support them directly. You get a capability to sell, not a software support obligation to run alongside your actual business.

Free 30-Day Trials, Opening Soon

Once the partner program opens, you'll be able to run KrakenCrypt on your own infrastructure, with your own data, no simulated demo and no sandbox limits, free for 30 days. We're onboarding select partners before opening it more broadly. Contact your LUX-LEET representative directly, or email info@lux-leet.com to get in early.

Request Early Access