Timeline for How to quickly detect incorrect password in encrypted file without compromising security?
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 18, 2015 at 14:48 | comment | added | Acetylator | And in this case, returning error saying that file is corrupted would be wrong - because file is not corrupted, it is the password that was invalid. So as you see, without using validator, decryption/decompression can return only two values - either OK or file is corrupted. And I need it to be able to return three values - OK, invalid password, file is corrupted. That was my point and the whole reason why I need to check whether provided password is correct before I start decrypting/decompressing it. That's all. | |
| Jun 18, 2015 at 14:46 | comment | added | Acetylator | If I use validator and supply invalid password, I get (not immediately, but relatively quickly - because of PBDKF) very clear error message saying that password is incorrect. If I don't use validator, I just have to try to decrypt/decompress until decompression returns an error (and it will, if I provide incorrect password). In this case decompressor will return error message saying that file is corrupted - because decompressor will be supplied with already decrypted data (which are going to be invalid) and decompressor has no idea at all that data were encrypted before. | |
| Jun 18, 2015 at 14:45 | comment | added | Acetylator | Fgrieu, not that it would change something, but I'll try to explain once again - I wanted a method that would allow me to check whether provided password is correct or not. Yes, using PBKDF2 slows this process a little bit, but since I am not trying to brute-force here, in my case this delay is negligible. Anyway, to check whether password is correct I have either to implement a validator sequence (as RNCryptor does), or just try to start decrypting/decompressing data without password validation. | |
| Jun 17, 2015 at 21:30 | review | Low quality posts | |||
| Jun 18, 2015 at 14:08 | |||||
| Jun 17, 2015 at 17:10 | comment | added | fgrieu♦ | I'm glad that your problem seems solved, but I do not understand how if you use RNCyptor's Password-based encryption: the validator in RNCyptor (draft) v4 does NOT much help to quickly check if the password is correct. It does save computing HMAC, but except for very large packets or small PBKDF2 parameters it is not a significant time saver, since the running time is dominated by the stretching of PBKDF2, which (as apparent here) must be performed before the validator check. | |
| Jun 17, 2015 at 16:51 | comment | added | Acetylator | Exactly, I was talking about draft v4. My bad, should have specified that. Concerning PBKDF2 - this is not a problem in my case per se, since all I wanted to know how to check password before trying to decrypt data. I will also have to check scrypt, I agree that it would be a better choice than PBDKF2. | |
| Jun 17, 2015 at 14:53 | comment | added | fgrieu♦ | Ah, so likely you are talking about RNCyptor (draft) v4. In the password mode, my reading is that checking a password using the validator still requires the expensive password-entropy-stretching with PBKDF2 (which BTW is far from state of the art, we have scrypt giving orders of magnitude more stretching) | |
| Jun 17, 2015 at 14:33 | comment | added | Acetylator | Well, RNCryptor is able to check password before the encryption starts - and this is exactly what I need. It generates "validator" sequence using specified password and then compares it to the validator from the file header. If both validators are the same, the password is correct. So it solves the problem of password checking. Concerning the bug in rnc_isEqualInConsistentTime - that's interesting, good that you noticed it, in my implementation I'll take care of it. Thank you! | |
| Jun 17, 2015 at 7:14 | comment | added | fgrieu♦ | I do not see that this RNCyptor solves the problem of fast check for incorrect password in its password variant (or that it can be done). Incidentally, there's a funny security near miss in rnc_isEqualInConsistentTime, supposed to compare the equality of bytestrings of variable length with resistance to timing attack: if self.lengthwas 256 (or a multiple of that), then empty otherData would be a match. It does not degenerate into a security problem in the context, since we do not use 2048-bit MACs. | |
| Jun 17, 2015 at 1:10 | history | answered | Acetylator | CC BY-SA 3.0 |