Specifying Raw Keys (rather than encrypting them with a password)

[ZelnickB]

Rationale

When many people create a password, they use common words. The problem is so severe that a 2024 analysis found that more than three million users in a database of leaked passwords used 123456. While most VeraCrypt users are presumably cybersecurity-savvy enough to use strong passwords that are difficult to guess, some may desire an even more secure solution. With the current functionality of the software, the best option that I know of is to use a randomly-generated password, but this simply adds another layer of complexity: the password is randomly generated, then the password is used to derive a pseudorandom key via a KDF, and then this pseudorandom key is used to encrypt a randomly-generated key.¹ In addition, it requires the user to externally generate a random password and then enter it into VeraCrypt, meaning that the password may be generated insecurely or passed over an insecure medium (like the clipboard). The burden on the user would be less if they were asked simply to store the key itself (rather than the value used to encrypt it). The biggest risk with this approach would be if the key was leaked (the volume would need to be re-encrypted with a different key for security), but this risk also exists with the password-based approach (if the volume and password are leaked, the password can be used to decrypt the key).

Desired behavior

The desired behavior of this feature is as follows:

• Add an option to generate the master key and have the user save that rather than a password.
  • Options for saving the key should include the format(s) selected from below for key input.
• For volumes that do not contain an encrypted copy of the key, add an option for decryption via raw master key input using a human-readable format. Some possible formats that should be supported are listed below:
  • One standardized method of conveying binary bytes with words of language, such as:
    • BCR-2020-012 Bytewords
    • PGP word lists
    • BCR-2024-008 Bytemoji (it would likely be difficult for users to enter keys this way but could be an interesting concept)
  • Base32 (not case-sensitive)
  • Base64 (more compact, but case sensitive and includes some non-alphanumeric characters)
  • Hexadecimal

Environment

For compatibility, this feature should be able to be used on all platforms.

I am using VeraCrypt 1.26.19 with FUSE-T on MacOS 15.2 Apple Silicon/ARM.

Footnotes

1. There is no benefit that I can think of to encrypting one random value using another random value—this simply necessitates two steps for encryption. Furthermore, though modern KDFs are cryptographically strong, this also introduces another attack surface in the event that a vulnerability is found in the KDF. ↩

[idrassi]

Thank you for the proposal.

Allowing users to specify the master key directly does simplify some aspects of the logic and can benefit certain specialized use cases. However, it also introduces challenges related to key management, limited functionality and greater potential security risks.

A master key cannot be memorized easily, so it must be stored securely and then copied when mounting a volume. This carries similar risks to using a password, but at least a password can be remembered without needing to store it anywhere. With a raw master key in text form, users will likely have to rely on clipboards or files, much like current keyfile approaches.

Another difference compared to the existing design is that if an attacker obtains a user’s password, they still need the corresponding header to retrieve the master key. In such a scenario, users can change their password to mitigate an ongoing attack. However, if the attacker obtains the raw master key itself (which may still be stored in a password manager), the only remedy is to re-encrypt the entire volume with a new key. That can be far more disruptive in practice.

As a result, key management becomes far more critical than it is with passwords. If this feature were implemented, there would need to be clear guidelines on how to store, handle and protect raw master keys. Using the same method as a password manager may reduce overall security because once a master key is compromised, re-encryption is the only solution.

Additionally, there are existing VeraCrypt workflows that wouldn’t translate as seamlessly to raw master keys. For instance, some users decouple the header from the volume itself, resulting in three components that must be combined to mount the volume (header file, volume without a header, and password/keyfiles). This setup allows splitting access between different users or different security levels (for example, lower security for the volume data, higher security for the header, and top security for the password). Once they’re ready to mount the volume, the user merges the header back with the data volume and supplies the password/keyfile. Raw master key usage would not replicate these workflows in the same way.

In short, raw master key usage may be beneficial only for niche use cases where storage and manipulation of the key are managed with extremely high security. Copying the raw master key to a clipboard for mounting is not particularly secure.

That being said, the feature could appeal to power users who want direct control of the encryption process. VeraCrypt could optionally allow them to specify the master key directly.

Regarding master-key import/export formats, a human-readable wordlist format doesn't seem particularly useful to me given the size of the key. Hexadecimal or binary file formats seem more practical.

Finally, the UI/UX aspects are very important for this feature. In my opinion, it would require significant work to implement correctly.

@ZelnickB : Any thoughts on potential benefits of wordlist-based or other encodings, versus hex or binary for raw key usage?

[ZelnickB]

I agree that this would be a feature for power-users and that most users would likely stick with the password-based method. However, I would imagine that VeraCrypt—by its nature—has a fairly infosec-savvy userbase and that a sizable number of users would make use of or consider using this feature in some situations. It would also allow for power users to perform external operations with the master key that may be applicable to their use case, like Shamir's secret sharing.

Since it does involve a unique set of risks, it would probably be reasonable to warn users before they used the proposed feature or to require them to enable some kind of "advanced mode."

Any thoughts on potential benefits of wordlist-based or other encodings, versus hex or binary for raw key usage?

@idrassi The benefit of a wordlist-based encoding would be that it would make it easier for users to store the key on human-readable physical media, like sheets of paper (which would mean that only physical access, and not any kind of hacking, would be able to reveal the key). People frequently use handwriting on paper and other non-electronic devices (see, for example, the Ledger Billfodl) to store Bitcoin wallet recovery phrases. Copying words is arguably less prone to errors than copying raw hex or even base32/base64, as mistakes can be easily prevented and detected. For example, using Bytewords, it would be much less likely for a user to mistakenly enter "veto" instead of "vial" than it would be for them to type e2 instead of e3 (the hexadecimal representations of the bytes represented by these words, respectively).

If the key was stored on some kind of digital medium, then as you mentioned, it would obviously make more sense to store it in raw binary format.