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.
Not abstract security claims. Specific attack scenarios.
Eliminates the danger of mass data leaks. If your database is compromised or stolen, all customer records remain scrambled and completely useless to attackers.
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.
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.
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.
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.
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.
Type any sensitive value, then flip the host toggle to see whether it's still readable elsewhere.
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... |
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.
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.
How the native C extension works under the hood, and what it takes to integrate it in production.
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.
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.
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.
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.
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 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.
Accepts the raw input in secure transient memory and validates it before any cryptographic work begins.
-Accepts the input bytes directly from the application request and validates size limits before any cryptographic work begins, in isolated transient memory.
Ensures the input stream complies with boundaries and flags abnormal inputs immediately, before they ever reach the cryptographic layer.
Strengthened via a salted, memory-hard hash (Argon2id) combined with a server-side secret, making brute-force economically infeasible even on GPU/ASIC hardware.
-Sealed inside an authenticated AES-256-GCM envelope. All transient key material is wiped from RAM immediately after.
CLEAREDKrakenCrypt 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:
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);
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);
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.
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.
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.
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.
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.