Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Key Encryption and Key Hierarchies #261

Open
radumarias opened this issue Dec 14, 2024 · 0 comments
Open

Key Encryption and Key Hierarchies #261

radumarias opened this issue Dec 14, 2024 · 0 comments
Labels
Milestone

Comments

@radumarias
Copy link
Member

radumarias commented Dec 14, 2024

Two-key encryption schema

We need to use a two-key schema for enhanced security, as described below. For that, we will have this flow:

  • when defining the key, we first generate a random DEK (data encryption key) used to encrypt the data
  • we then generate a random KEK (key encryption key) used to encrypt the DEK
  • from the password, we derive a key and encrypt the KEK
  • save DEK and KEK in different files so usually they're not compromised together. For now, keep both in data-dir/security folder

Key obfuscation

DEK and KEK are based on a cipher but have a maximum of 32 bytes. So brute force consists of breaking a 32-byte file. To make this harder, we need to use this schema:

  • after we have the 32 bytes of the key we group bytes in random size groups of 1-4 bytes
  • when writing a group, before, between, and after the group, we write chunks of random data of random size between 1 - 512-bit
  • we save the offset and size of each key group and the length of each random padding at the beginning of the file so we can read the key

Two-key encryption schema details

Encryption of Keys at Rest

Key Encryption and Key Hierarchies:

    In encryption-at-rest systems, data is typically encrypted using a data encryption key (DEK).

    The DEK itself is encrypted using a key encryption key (KEK), creating a hierarchy for secure key management.

Master Key or Recovery Key:

    The KEK or master key is often derived from a secure user input like a passphrase, recovery phrase, or another high-entropy secret.

    This derived key functions similarly to a recovery phrase in cryptocurrency wallets, acting as the root for all subsequent encryption keys.

How It Works

Key Derivation:

    A passphrase or phrase-like secret (e.g., a recovery phrase) is passed through a key derivation function (KDF) such as PBKDF2, Argon2, or bcrypt to produce a high-entropy key.

    This derived key encrypts the KEK, which in turn encrypts the DEK.

Key Backup:

    For recovery, the passphrase or root key (analogous to a recovery phrase) is stored securely (e.g., written down offline or in a secure hardware module).

    The passphrase allows access to the encrypted KEK, which then decrypts the DEK to access the data.

Reuse:

    Just like recovery phrases in crypto wallets, the passphrase or root key can be reused multiple times to decrypt the KEK and access the data.

    It is not regenerated unless the user explicitly changes the master encryption setup.

Example in Practice

Full Disk Encryption (FDE):

    Tools like BitLocker, VeraCrypt, and LUKS often encrypt the encryption key using a password or recovery key.

    If you lose the password, you can use the recovery key to decrypt the volume.

Cloud Encryption Services:

    Many cloud platforms (AWS, Azure, GCP) encrypt data at rest by default using customer-managed or provider-managed keys.

    A recovery passphrase or hardware security module (HSM) backup often provides a fallback if the primary keys are inaccessible.

Security Best Practices

Use a high-entropy passphrase or recovery key for encryption systems.

Store recovery phrases/keys securely (offline, in tamper-proof hardware, or a safe location).

Use hardware security modules (HSMs) or trusted platform modules (TPMs) for enterprise-grade encryption management.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant