Key Management Best Practices

Why key management matters more than algorithms

Choosing AES-256-GCM over something weaker is important, but it’s not the hardest part. Incidents usually come from:

• Keys left in source code or config.
• Shared passwords used as “keys”.
• Missing rotation or uncontrolled copies.

Key management is about where keys live, who can use them, and how they change over time. Without that, “we use AES-256-GCM” is a weak statement.

In zero-knowledge systems like Inkrypt, we partially sidestep this by deriving keys from user passwords in the browser using PBKDF2 with 310k iterations and never storing those keys server-side.

Key lifecycle: generate, store, use, rotate, destroy

A realistic key management strategy follows the full lifecycle:

• Generate:
• Use cryptographically secure random number generators.
• Avoid human-chosen keys or predictable sources.
• Store:
• Keep keys in dedicated systems (HSMs, KMS, secure vaults).
• Never hard-code keys in source, images, or client apps.
• Use:
• Limit which services can request decryption.
• Prefer envelope encryption (wrap data keys with master keys).
• Rotate:
• Regularly rotate keys and re-encrypt where feasible.
• Have a tested process to migrate without downtime.
• Destroy:
• Remove old keys when no longer needed.
• Treat key deletion as a real, logged operation.

Formalising this in policies and code is what separates ad hoc crypto from something you can defend to auditors and attackers alike.

Password-derived keys vs centrally managed keys

There are two common models:

• Centrally managed keys:
• Generated and stored in HSMs or cloud KMS.
• Used by services to encrypt and decrypt.
• Good for server-side and account-based systems.
• Password-derived keys:
• Derived from user passwords using KDFs like PBKDF2.
• Often used in zero-knowledge designs where the provider never sees keys.

Inkrypt uses the second model:

• Your note password stays in the browser.
• We derive an AES-256 key using PBKDF2 (310k iterations) via the Web Crypto API.
• Notes are encrypted with AES-256-GCM; server stores only ciphertext and parameters.

That avoids server-side key storage entirely but comes with trade-offs:

• No password reset or key recovery.
• Users must manage their own passwords wisely.

For more on that architecture:

• See “Zero-knowledge encryption: what it actually means when we can't see your data”.
• See “Why we encrypt in the browser (and what happens to your password)”.

Practical key management patterns for teams

For systems that use centrally managed keys:

• Prefer cloud KMS or HSM-backed services over application-level secrets files.
• Implement envelope encryption:
• Data keys encrypt data (using AES-256-GCM).
• Master keys in KMS/HSM encrypt data keys.
• Only limited services can unwrap data keys.
• Separate roles:
• Developers should not have direct access to production keys.
• Operations staff use controlled, audited paths for key operations.

For client-side or zero-knowledge systems:

• Use strong KDFs (PBKDF2 with high iteration counts) for password-based keys.
• Avoid ever sending raw keys to servers.
• Make it clear that loss of passwords means loss of access; no hidden backdoors.

This split is healthy: some systems rely on central key management; others, like Inkrypt, rely on user-held secrets.

FAQ: Key management best practices

Q1. Where should I store encryption keys in a cloud environment?

Use cloud KMS or HSM-backed vaults, not environment variables, code, or config files. Limit which services can call decryption APIs and log their usage.

Q2. How often should keys be rotated?

There is no single number, but rotating regularly (for example, annually or after major incidents) and after suspected compromise is a minimum. Data keys can be rotated more frequently than master keys.

Q3. Are password-derived keys safe?

Yes, if you use strong KDFs (like PBKDF2 with 310k iterations) and strong passwords. This is the model used by zero-knowledge tools like Inkrypt, where keys never leave the client.

Q4. What’s the biggest mistake teams make with keys?

Hard-coding keys in repositories or images, and then treating those deployments as if they provided strong encryption. Once a key is in source control, assume it is compromised.

Q5. How does Inkrypt handle key management?

Inkrypt does not store decryption keys at all. The browser derives keys from passwords using PBKDF2, encrypts notes with AES-256-GCM, and discards the key after use. The server holds only ciphertext and public parameters.

Where to go next

To see a concrete implementation of password-derived keys and zero-knowledge encryption:

• Read “Zero-knowledge encryption: what it actually means when we can't see your data”.
• Read “Why we encrypt in the browser (and what happens to your password)”.

And if you want to offload some high-sensitivity note storage to a system that removes server-side key management entirely, start using Inkrypt at https://www.inkrypt.online.