Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
The client knows the cleartext password anyway, knowledge of salt / IV are rather irrelevant. If the system is compromised it is rather trivial to intercept the password when it's entered the next time.
Salts are useful to require a rainbow table to be built for that particular salt, which isn't really difficult, but requires effort (time, computing) from an attacker. Rainbow tables are more relevant to password hashing though, rather than symmetric encryption of rather large amount of data, where they're not very practical.
Regarding symmetric encryption (RSA-CBC specifically), using a bad IV is a big nono - it can weaken the encryption significantly. IVs should be random, from a cryptographic RNG.
The importance of not using static salt / IVs.
I've been working on a project that encrypts files using a user-provided password as key. This is done on the local machine which presents some challenges which aren't present on a hosted environment. I can't generate random salt / IVs and store them securely in my database. There's no secure way to store them - they would always end up on the client machine in plain text.
A naive approach would be to use static data as salt and IV. This is horrendously harmful to your security for the reason of rainbow tables.
If your encryption system is deterministic in the sense that encrypting / hashing the same string results in the same output each time, you can just compile a massive data set of input -> output and search it in no time flat, making it trivial to reverse engineer whatever password the user input so long as it's in the table.
For this reason, the IVs and salt are paramount. Because even if you generate and store the IVs and salt on the user's computer in plaintext, it doesn't reveal your key, but *does* make sure that your hashing / encryption isn't able to be looked up in a table
rant