M1-03: Define Crypto Spec & Encrypted Entry Envelope

Alex Johnson
-
M1-03: Define Crypto Spec & Encrypted Entry Envelope

Welcome to the M1-03 discussion! Today, we're diving deep into the heart of our security architecture by defining the crypto spec and the encrypted entry envelope format. This is a crucial step in ensuring that all your data is protected with the highest standards of encryption. Our goal here is not just to meet compliance but to build a system that you can trust implicitly with your sensitive information. We'll be outlining the precise methods we'll use for key derivation, the encryption algorithms that will safeguard your data, and the structure of the encrypted envelope that will hold your valuable entries. This comprehensive approach guarantees that your data remains confidential and secure, no matter where it resides.

Understanding Key Derivation: From Password to Master Key

The journey of securing your data begins with a strong foundation: key derivation. This is the process where your secure password is transformed into a master key, which then acts as the root of trust for all your encryption and decryption operations. We'll be implementing a robust key derivation function (KDF) that is designed to be computationally intensive, making it incredibly difficult for attackers to guess or brute-force your master key, even if they manage to obtain your hashed password. This process involves multiple rounds of hashing and salting, ensuring that each master key is unique and highly resistant to precomputation attacks like rainbow tables. The strength of your password directly correlates to the security of your master key, so we always encourage the use of strong, unique passwords. The specific KDF we've chosen balances security with performance, ensuring that key generation is fast enough for a seamless user experience while providing the strongest possible protection against unauthorized access. This meticulous approach to key derivation is the first line of defense in our multi-layered security strategy, setting the stage for the secure handling of all your encrypted entries.

The Powerhouse Algorithm: AES-GCM Encryption

When it comes to protecting your data, we're not cutting any corners. We've selected AES-GCM as our primary encryption algorithm. AES, or Advanced Encryption Standard, is a widely recognized and highly secure symmetric encryption standard adopted by governments worldwide. It's known for its speed and robust security. We're specifically opting for the GCM (Galois/Counter Mode) implementation. GCM is an authenticated encryption mode, which means it not only encrypts your data but also provides integrity and authenticity checks. This is critical because it prevents attackers from tampering with your encrypted data without detection. Think of it as a digital seal on your data; if the seal is broken, you know the data has been interfered with. AES-GCM ensures that the ciphertext you receive is exactly what was sent, and it hasn't been altered in transit or while at rest. The combination of AES's strong confidentiality and GCM's authenticated encryption capabilities provides a powerful, all-in-one solution for securing your sensitive information. This means you can be confident that your data is both private and has not been tampered with, a dual guarantee that is essential in today's digital landscape.

Per-Entry Key Strategy: Granular Security

To further enhance security and manageability, we're implementing a per-entry key strategy. Instead of using a single master key to encrypt every single piece of data, we generate a unique, ephemeral encryption key for each individual entry. This adds a significant layer of security. If, hypothetically, one of these per-entry keys were compromised (which is highly unlikely given our other security measures), the damage would be limited only to that specific entry. All other entries would remain secure, protected by their own unique keys. This strategy is considered a best practice in modern encryption for several reasons. Firstly, it limits the blast radius of any potential security incident. Secondly, it simplifies key rotation and management; if a key needs to be rotated, it only affects the entries associated with that key. The per-entry keys are themselves encrypted (or 'wrapped') using a key derived from your master key, ensuring that only you, with your master password, can access the keys needed to decrypt individual entries. This granular approach to encryption provides an exceptional level of security and resilience, ensuring that the compromise of one element does not lead to the compromise of the entire system. It's a sophisticated method that ensures the security of each data point individually, giving you peace of mind.

The Encrypted Entry Envelope: What’s Inside?

When your data is encrypted, it doesn't just exist as raw ciphertext. It's neatly packaged within an encrypted entry envelope. This envelope is a structured format designed to hold all the necessary components for your data to be securely stored and later decrypted. The essential fields within this envelope are: iv (Initialization Vector), ciphertext, wrappedEntryKey, createdAt, updatedAt, and date. The iv is a random or pseudorandom number used in conjunction with the encryption key to ensure that even if you encrypt identical pieces of data, the resulting ciphertexts will be different. The ciphertext is the actual encrypted form of your data. The wrappedEntryKey is the unique, per-entry encryption key that we discussed, encrypted with a key derived from your master password. The createdAt, updatedAt, and date fields are metadata that help in organizing and managing your entries; these fields themselves will be stored in a way that respects our security policies, ensuring no sensitive plaintext information is leaked through them. This well-defined envelope structure ensures that all the required cryptographic material is present and correctly organized for efficient and secure handling of your encrypted data, making decryption straightforward and secure.

The Golden Rule: No Plaintext at Rest!

Perhaps the most critical principle guiding our encryption strategy is the “no plaintext at rest” rule. This means that absolutely no sensitive user data will ever be stored in its original, unencrypted form on our servers or any other storage medium. Every piece of sensitive information is encrypted before it is stored. This is the fundamental bedrock of our security promise. While this rule is strict, we recognize that some metadata is necessary for the system to function. Therefore, we've carefully considered what metadata is allowed and how it will be handled. Generally, non-sensitive, system-generated information like timestamps (createdAt, updatedAt) and potentially anonymized or aggregated data used for operational analytics may be stored. However, any metadata that could indirectly reveal sensitive information about your entries or your usage patterns will also be encrypted or handled with extreme care. Our commitment to

You may also like