Everyone knows Argon2id is a slow hashing algorithm, and that's on purpose, all is good.
When creating an Argon2id object a lot of parameters are needed to be taken into consideration ultimately settling on a configuration that is strong enough but within the amount of time that you're willing to wait for the operation to happen.
I'm using Argon2id in a cryptographic application where I take a user password, generate a random salt of 32 bytes and use them to create a hash of a key to use for AES-GCM encryption.
I am currently generating 1 salt for 1 key per operation. An operation can encrypt 1 or n files, my current tests are running for like 550 files. Everytime I start an encryption operation, even if I'm using the same password, a new salt is generated, but is used for all files that will be encrypted within the operation.
An alternative generating a new salt, which would result in a new key for the same password for each file, which is obviously more secure, but painfully way more slower even when I run it with a degree of parallelism of 8 concurrent file.
The single key approach uses:
768 MB RAM
This clocks at 3.3 seconds hashing operation that is done once and the rest is lightning fast (finished in less than 10 seconds with 8 files in parallel)
The multiple keys approach uses:
32 MB RAM
This clocks at 400 ms hashing operations that are done for each file, those parameters provide a somewhat acceptable (finishes in nearly 2 minutes with a 8 files in parallel)
My rationale for using the same key per encryption operation was that you can consider the 'n' files (in this case 550) as a single zip file that has all of them, encrypted with 1 key, the security would be equivalent. If you are able to break the zip's encryption you get access to the 550 files, unless my logic is flawed.
I need an advice if the trade off in Argon2id parameters for unique salts and slower time is more worth it, or is my initial approach acceptable in the world of cryptography. Thanks!