Add ScryptIdentity.SetMinWorkFactor and document risk of online decryption oracles

[FiloSottile]

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]

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]

@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.