minimum scrypt work factor

[rmculpepper]

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.

[FiloSottile]

This is a very good observation. Online password decryption oracles are discouraged for this and other reasons, as you point out, but we should have a SetMixWorkFactor in the library and a warning in the spec and the docs about the use case in general and the risk of too low work factors. It might even be worth introducing a default minimum in the next library version.

Pretty glad we held the line on automated CLI password decryption.

/cc @str4d