Passphrase encryption security

[emanjon]

Thanks for implementing and maintaining this. This seems like a huge improvement over the archaic OpenSSL and GPG file encryption applications. All linux distributions should ship with an acceptable file encryption application.

I read the format specification
https://github.com/C2SP/C2SP/blob/main/age.md

While the passphrase encryption is a big improvement over OpenSSL and PGP, it does not seem to align with modern requirements for use of passwords. In SP 800-63b [1], NIST makes the following mandatory requirements:

• Verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised.
• If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.
• In addition, verifiers SHOULD perform an additional iteration of a key derivation function using a salt value that is secret and known only to the verifier. This salt value, if used, SHALL be generated by an approved random bit generator [SP 800-90Ar1] and provide at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). The secret salt value SHALL be stored separately from the hashed memorized secrets (e.g., in a specialized device like a hardware security module).

I think these requirements make a lot of sense and my understanding is that age is not doing this. I don't think there is any reason to require this for password databases but not for password encrypted files. When commenting on NIST SP 800-132, one of Ericsson's comments [2] was that NIST should align SP 800-132 with SP 800-63b regarding these requirements.

Cheers,
John

[1] "Digital Identity Guidelines"
https://pages.nist.gov/800-63-3/sp800-63b.html

[2] "Public Comments on SP 800-132, Recommendation for Password-Based Key Derivation: Part 1: Storage Applications"
https://csrc.nist.gov/csrc/media/Projects/crypto-publication-review-project/documents/initial-comments/sp800-132-initial-public-comments-2023.pdf

[FiloSottile]

I am not a fan of designing based on authority requirements unless the goal is compliance with the authority (which is not a goal of age). However, happy to discuss the security benefits of (A) password strength checking and (B) secret salts.

B makes no sense to me, if you have a place to store a secret salt, just store a private key there and forego passwords entirely. (This is also a good reason for it to be in SP 800-63b and not SP 800-132: encryption unlike authentication doesn't have the concept of a "verifier".) How did you envision this working in age?

As for A, maybe we could do some checking in the CLI, although mandating it in the spec feels like overreaching, partially because it's hard to specify what exactly counts as commonly used.

[emanjon]

I am not a fan of designing based on authority requirements unless the goal is compliance with the authority (which is not a goal of age).

I agree. The reasons to align with authority requirements would be compliance or that the requirements make sense. I do for example think it is very good that age use scrypt instead of PBKDF2, which is the only thing that is NIST approved.

However, happy to discuss the security benefits of (A) password strength checking and (B) secret salts.

B makes no sense to me, if you have a place to store a secret salt, just store a private key there and forego passwords entirely.

I kind of agree, but my conclusion would then be that the passphrase solution offers quite low security. An attacker getting hold of a the files on a computer with a password storage following NIST requirements cannot brute force any of the stored passwords. An attacker getting hold of age encrypted files with user chosen passwords would likely be able to brute force a majority of them. Using passwords generated by age solves this, but would be still be vulnerable as the user would likely store it insecurely. I think combining passwords and a second factor secret makes a lot of sense, but then the password and second factor secret should maybe ulock the recipient X25519 private key instead of being used in age.

(This is also a good reason for it to be in SP 800-63b and not SP 800-132: encryption unlike authentication doesn't have the concept of a "verifier".) How did you envision this working in age? As for A, maybe we could do some checking in the CLI, although mandating it in the spec feels like overreaching, partially because it's hard to specify what exactly counts as commonly used.

The whole sentence is "When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised."._ I think age could do this when the user suggest a passphrase to encrypt a file. But that would require downloading a large breach corpus. Not sure how good strength checking without a breach corpus is.

[cipriancraciun]

I kind of agree, but my conclusion would then be that the passphrase solution offers quite low security. An attacker getting hold of a the files on a computer with a password storage following NIST requirements cannot brute force any of the stored passwords. An attacker getting hold of age encrypted files with user chosen passwords would likely be able to brute force a majority of them.

The use-case you are describing seems to be focused mainly on "encrypted file storage", as in the person that encrypts the data, is the person that should decrypt the data.

However, how would such a "secret salt" work when age is used to exchange information between different persons. (There is now the need for an out-of-band secret exchange mechanism.)

Also, can this "secret salt" be reused (for multiple files? for multiple recipients?)