1

I read about Recommended # of iterations when using PBKDF2-SHA256?

I have also read in Why not just use a small but unusual number of hashing rounds? that when there are multiple password to protect, the moment one is cracked the hacker will know for all passwords which is the number of iterations required. But if I have to protect just one file with one password (or a very limited number of files with the same password), does it make sense if instead of selecting 100000 iterations to protect the password I use a "random" number like 97334? Or is there an easy way for the attacker to know how many iterations they need to run?

The tool used in OpenSSL, and the attacker will have the encrypted file(s). The number of iterations to encrypt the key is not visible to the attacker.

Antonio
  • 113
  • 4
  • 2
    Why would you assume an attacker knows the algorithm but not the number of iterations? – Gamer2015 Aug 02 '21 at 18:11
  • @dandavis usually the output is just the password based key of the specified length. Parameters like salt and iterations have to be saved independently (assuming the iterations count is not fixed) – Robert Aug 02 '21 at 20:59
  • @dandavis I think you mix up the scrypt key derivation algorithm with the *nix scrypt command. The first only outputs the generated key see https://en.wikipedia.org/wiki/Scrypt – Robert Aug 02 '21 at 21:07
  • @ThoriumBR Thank you for pointing out to that question, it does answer the question. I have edited to specify one detail which is different in my use case: I have to protect just one password (or a limited number of strong passwords). Looking at the answers there, it still looks that "randomizing" my number of iterations still makes sense. – Antonio Aug 03 '21 at 08:50
  • @Gamer2015 After all I am using the most recommended algorithm or a very standard library. – Antonio Aug 03 '21 at 09:03
  • If you are ding everything else right, then a non-standard amount of iterations won't hurt as long as the the iteration count is not low. – nobody Aug 03 '21 at 09:21
  • @Antonio The correct answer would be that these things are to be considered public information. The only thing you should assume the attacker not to know are the keys. Read up of Kerckhoff's Prinziple for more information. – Gamer2015 Aug 03 '21 at 11:05
  • @Gamer2015 I agree with you, the only thing is that in my very specific case the number of iterations is "as protected" as the password – Antonio Aug 03 '21 at 12:05
  • It's not about agreeing with me or not, the only thing about your cryptosystem that you should treat as secret are the keys. The KDF-algorithm and it's parameters must be considered public in a security analysis of your system, you must not rely on their secrecy. An attacker with read access to your database will also have read access to the source code. – Gamer2015 Aug 03 '21 at 12:41
  • 1
    If you still don't agree with me it seems like you want to use the number of iterations as a key. A key should have enough entropy, a number less than 2^64 won't be of any value here. As Anders pointed out in his answer it would be better to have a seperate secret you can use as pepper. One attack vector I could think of when considering the number of iterations as a key would be timing attacks. – Gamer2015 Aug 03 '21 at 12:47
  • @Gamer2015 The general case doesn't necessarily apply to any specific case. As I said, in my specific case the number of iterations is as protected as the password is, i.e. password and number of iterations have to be discovered at the same time. I am giving a lot of entropy to my password, what I am wondering if I can get some entropy for free through the number of iterations. – Antonio Aug 03 '21 at 12:49
  • You might get some extra entropy. The number has to be small though, otherwise the hashing would take too long, thus giving little entropy. Prepending pepper (giving more entropy) to your password and using a fixed number of rounds would be better. Your approach also has some theoretical weaknesses. If the attacker can use your hashing algorithm with his password he could try a timing attack, guessing the order of iterations. If he could also see the created hash (chosen plaintext attack) he could calculate the number of iterations in the same time you can verify the password. – Gamer2015 Aug 03 '21 at 13:32
  • Also: The general guidelines for computer security should be taken quite seriously, they stand for a reason and are the result of decades of computer security research and vulnerabilities. – Gamer2015 Aug 03 '21 at 13:33

1 Answers1

1

You are essentially trying to use the number of rounds as a pepper. Only problem is that the number of rounds is included in the full output of PBKDF2, and therefore known to the attacker.

$pbkdf2-sha256$6400$.6UI/S.nXIk8jcbdHx3Fhg$98jZicV16ODfEsEZeYPGHU3kbrUrvUEXOPimVSQDD44
               ^^^^ There it is!

You could use a different number of rounds than printed to confuse the attacker, but then you would be fiddling with the algorithm and risk making a fatal mistake.

An actual pepper, encrypting the hash or just increasing the entropy of the password would be better ways to increase your security.

Anders
  • 64,406
  • 24
  • 178
  • 215
  • In the specific library I am using to encrypt, the number of iterations doesn't seem to be visible in the encrypted file. Maybe I didn't understand correctly what you mean: are you saying that there is a program that can see from an encrypted file how many iterations where performed to protect the key? I do understand and agree that having a longer/stronger/higher entropy password is a certain way to improve security, I wonder if an obfuscated the number of iterations can make the work of the attacker even more difficult. – Antonio Aug 03 '21 at 12:16
  • 1
    I didn't check, but I don't think outputting the number of rounds is part of the standard. I don't see any reason why you couldn't just strip out that part and just store the hash, assuming that you store the number of rounds somewhere else (like hardcode it). – nobody Aug 03 '21 at 12:20
  • @Antonio Are you using PBKDF for hashing passwords for user authentication, or for stretching encryption keys? I assumed the former, perhaps incorrectly. Sorry if my tag edits made your question make less sense. – Anders Aug 03 '21 at 13:59
  • @nobody If the use case is password hashing for user authentication, it is good practice to treat the full string as a single unit, and let a well tested hash library take care of the details. But maybe that is not the use case here. – Anders Aug 03 '21 at 14:01
  • @Anders I am protecting a file with a password, so I think the answer to your question is "stretching encryption keys". Should my question be rephrased? – Antonio Aug 03 '21 at 16:52
  • @Antonio Mentioning that in your question would be a good idea. For someone to be able to answer the last question in your post, more information is needed. Does the attacker have the file? Is the number of iterations in the file? How was the file generated? – Anders Aug 04 '21 at 16:55
  • @Anders I tried to modify accordingly my question – Antonio Aug 06 '21 at 13:28