Suppose a less-than-trusted server is used to store users' confidential data (encrypted at the client side), and both tasks - authentication and encryption/decryption - should be doable with a single password. Would it be enough to:
- Strenghten the password with a slow key derivation function and a trivial salt
kas the SRP "password", authenticating with the server and receiving the ciphertext;
- Decrypt the ciphertext to get the actual key(s) to be used for signing, encryption, etc.
A malicious server (low risk) would have to perform an offline dictionary attack - on the verifier or on the ciphertext - to retrieve
k, while an external attacker (higher risk) would only be able to do online attacks (since he has access neither to the verifier nor the ciphertext), unless he gets a copy of the database - which would just put him in a similar situation of the server
Is this reasoning correct? Any flaws I didn't anticipate? Some notes:
- I say the salt is "trivial" because it's either: a) empty; b) derived from the username; c) random, but the server will give it to anyone who requests it. Normally that would be a concern, but here the key never leaves the client machine, so it doesn't matter if two users have the same key.
One of my concerns is that an attacker could create a rainbow table targeted at a particular user, then get the database and almost immediatly log in as that user, since brute-forcing the verifier or the ciphertext is quicker if you have a list of candidate keys rather than a list of candidate passwords (which still need to be stretched before becoming keys).
Of course, if an attacker has that computing power (of if the password was weak) any leaked ciphertext will eventually be cracked, but future harm could be avoided if the server were stronger against this scenario (before learning about SRP I designed a more convoluted protocol that took this into account, but was more wasteful and had open questions).
- [For my particular case] All these are out of scope of the question (assume already figured out): all communication will be over TLS, option to use proper keys and 2-factor auth will be given (but not mandated), the client code will not come from the less-than-trusted server, MACs will be used, etc.