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

Add ScryptIdentity.SetMinWorkFactor and document risk of online decryption oracles #417

Open
FiloSottile opened this issue May 9, 2022 Discussed in #413 · 2 comments
Labels

Comments

@FiloSottile
Copy link
Owner

Discussed in #413

Originally posted by rmculpepper May 2, 2022
When a user attempts to decrypt a file with an scrypt passphrase, the work factor that protects the user's passphrase is determined by the age header. If the user accepts files from untrusted sources and attempts to decrypt them, an attacker can submit files with the (log) work factor set as low as 1. If this is automated and if the attacker can observe decryption success vs failure, they can guess passwords at a rate far higher than the user would expect.

I'm raising this on the general principle that the protection of user secrets should not depend on parameters that an attacker can control. The command-line tool seems to discourage scripting decryption with passphrases, but this might be more of an issue for the library and other implementations. I think there is already an implicit assumption that the user should not do online passphrase-based decryption (there's a related comment about a different issue here: https://github.com/str4d/rage/blob/main/age/src/scrypt.rs#L150). I think either the spec should say "don't do that" emphatically, or it should recommend or require implementations to reject scrypt stanzas with a work factor under a reasonable minimum.

@Macil
Copy link

Macil commented May 10, 2022

This is a little awkward for me because just yesterday I was experimenting with using securely-generated long random passphrases with a minimal work factor to speed up decryption. (I'm storing age-encrypted files on a remote file host that I don't want to trust plaintexts to, and I'm using a reverse HTTP proxy that transparently decrypts the files while fetching them, similar to str4d/rage#233. Recipient-based encryption would have mostly worked for my use-case, but I prioritized passphrase-based because of long-term quantum resistance, and partly because it verifies the files as coming from me, but for that maybe it'd be better if I was using some kind of asymmetric signing outside of age so that the signing is done by a key of mine that the reader program doesn't have.)

It would help my use-case if there's a way to opt out in the CLI from the enforced minimum work factor during decryption, or if there was some other supported way to do symmetric encryption within age that didn't involve work factors (like symmetric key file support or some kind of plugin support that could implement symmetric key files; is this already supported?).

(I was considering making a feature request that files encrypted with an autogenerated passphrase should have a minimal work factor by default because a high work factor seems unnecessary in that case, but then I realized it would awkwardly mean that files with a high work factor are announcing themselves as having weak passphrases.)

@FiloSottile
Copy link
Owner Author

@Macil thank you for all the details about the use case, this is really helpful in setting direction.

Here is some stuff we are working that will probably help address your use case:

  • Plugin support is coming, and it will allow writing simple symmetric encryption plugins for post-quantum resistance.
  • We will allow plugins to opt in to the authentication properties of scrypt recipients, so that some plugins can be authenticated just like passwords, be it a X25519 or symmetric plugin.
  • There's discussion of post-quantum plugins, and we'll eventually recommend one.
  • The CLI will not actually start having a minimum work factor anyway, since it will never gain an automated way to input the decryption passphrase, so it can't be targeted in oracle attacks.
  • Lots of people want to automate password encryption though! So we'll make a age-plugin-passphrase plugin like sshpass with all the option. That one will have a minimum work factor and an option to configure it.

Defaulting autogenerated passphrases to a low work factor is an interesting thought, but I think you might be right that it's not worth the unexpected privacy leak and the complexity.

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

2 participants