1

I read about recommendations about secret keys (or password as rfc8018 call it), one of them is to change the password from time to time.

I would like to know: is there some best practice for this change of password?

I found this reference in the RFC with the following information:

changing a password changes the key that protects the associated DPK(s). Therefore, whenever a password is changed, any DPK that is protected by the retiring password shall be recovered (e.g., decrypted) using the MK or the derived keying material that is associated with the retiring password, and then re-protected (e.g., encrypted) using the appropriate MK or the derived keying material that is associated with a new password.

I understood from this text, that I have to re-protect again. But when and by who this process has to be made? "re-protect" could be a batch process? Or is there a better option?

In short, how to carry out this process without reinventing the wheel?

Clarifying the reference to password

I believe IMHO, that the word password leads to confusion, I have used the word password since the RFC refers to it as follows:

"In many applications of public-key cryptography, user security is ultimately dependent on one or more secret text values or passwords. Since a password is not directly applicable as a key to any conventional cryptosystem, however, some processing of the password is required to perform cryptographic operations with it. Moreover, as passwords are often chosen from a relatively small space, special care is required in that processing to defend against search attacks."

Reading the text, I think this password is not related to user passwords (I could be wrong), For me this is a secret that can be used by the entire application, in my case to encrypt a text.

I hope I have clarified the point, Thank you.

3
  • 1
    @Luc The document refers to key derivation and encryption, not user authentication. Other than knowing there are better choices than PBKDF2, not much of the usual advice transfers. – Future Security Apr 14 '20 at 0:31
  • @FutureSecurity Oh I'm stupid, I didn't read this question in enough detail. It's indeed not about changing PBKDF2 parameters but changing an encryption key. Thanks for pointing that out, I've removed the useless comments. – Luc Apr 14 '20 at 0:35
  • I have edited my question, adding some clarification, because I think the word password leads to confusion – KCOtzen Apr 17 '20 at 14:29
2

In the context of having to enter your password to access your encrypted information: you don't derive the key that encrypts data using PBKDF2.

  • Every file (or thing) is encrypted with a unique randomly generated "session" key and salt (e.g. a 256-bit encryption key)
  • that per-file "session key" is encrypted with a Master Key (and salt)
  • the master key is also a randomly generated 256-bit encryption key

That Master Key is then encrypted with a key derived from the user's password.

enter image description here

The basic goal is that:

  • each file is encrypted with a cryptographically strong 256-bit key
  • all the session keys are encrypted with a cryptographically strong 256-bit key
  • and the master key is encrypted with the user's password

The virtue of this is that data and the session keys are protected with an excellent cryptographic keys, and are not the weak points.

And when the user wants to change their password:

  • you don't have to decrypt and re-encrypt all their data
  • you don't even have to decrypt and re-encrypt all the per-file session keys
  • you only have to decrypt and re-encrypt their master key
3
  • Thanks @IanBoyd, I have edited the question, adding some clarification, because I think the word password leads to confusion. – KCOtzen Apr 17 '20 at 14:28
  • Very good. What tool did you use for the diagram? I assume green means the data is stored at rest and red means it's not. – Future Security Apr 17 '20 at 20:31
  • i used draw.io. Red means danger (super-secret stuff laying around). Green means safe. – Ian Boyd Apr 17 '20 at 23:24
0

I read about recommendations about secret keys (or password as rfc8018 call it), one of them is to change the password from time to time.

It doesn't say anywhere in the NIST document to change passwords from time to time. RFC 8018 doesn't call secret keys passwords.

But when and by who this process has to be made?

When? whenever a password is changed That is when you derive new keys from the new password.

Who? Any one of the people who want to keep the data secret, has write access to the storage medium, and knows the password, master key, or derived keys. Probably another employee.

In short, how to carry out this process without reinventing the wheel?

There are many applications that support password based encryption. KeePass2 and Veracrypt, for example. There are of course many, many, many, more. Almost all are extremely imperfect. I'm not comfortable citing closed source, commercial, or projects with small user bases. Other people might include GPG (hard to use correctly) or 7zip (questionable).

It's too broad a topic to analyze the merits and flaws of every program or even a few of them. It would be a lot of writing for me and is not really what this site is meant for.


If you're asking as a software developer... Stay far away from this. Allow someone else with a formal background in cryptography to do that work. There are countless subtle ways to get things wrong with devastating impacts on security. It's important for the programming team responsible to know every one of those ways.

(For reference, that NIST doesn't even require remotely arcane knowledge within the field of cryptography to understand. Most subjects and documents are far more complex. On top of that, the NIST document is pretty incomplete and isn't up to date. So working from this document as a starting point is insufficient.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.