I'm questioning the password used in a key derivation function, whether It makes sense to make it unique for every generated symmetric key and why

  • I'm questioning the password used in a key derivation function, whether It makes sense to make it unique for every generated symmetric key and why – NowsyMe Jul 4 at 15:51
  • 1
    That’s a much clearer question; I recommend you edit your original question to be exactly that. – John Deters Jul 4 at 16:08
  • thank you for feedback – NowsyMe Jul 4 at 18:01

Key Derivation functions like PBKDF, KDF1, and, HKDF can use a single password to derive a key. To derive an additional key with the same password the common approach is using info as in HKDF which has two steps.

Extract : HKDF-Extract(salt,IKM)->PRK

Expand: DF-Expand(PRK,info,L)->OKM,

  • IKM is the Input Key Material
  • OKM is the Output Keying Material
  • PRK is Pseudo Random Key

The Extract mechanism is important if the IKM is not good random material. The salt strength the PRK. For passwords, this is the case.

With the info one can derive multiple keys ( a python code is included). This is due to domain separation.

The bottleneck is the strength of the password. If one uses a good mechanism like diceware with good entropy then it is beyond attack.

Password-based key generation is usually used for file/volume encryption like Vercrypt or password managers. For end-to-end communication Diffie-Hellman key exchange is used mostly with the ECC version. The established( exchanged) key then used with a KDF to derive a symmetric key.

For encryption, one doesn't need to change a key often. Since there is a good mechanism to reuse a key, the IV/Nonce as in CBC and CTR mode. With the IV/nonce these modes can achieve the standard notion of security IND-CPA.

Therefore, theoretically once can use one good password to secure everything. Practically, this is not preferred. Separating the domains with multiple passwords is better in practice than in turn will require a password manager like keypass.

| improve this answer | |

A password based key derivation function, such as PBKDF2, is designed to always output the same key given the same input password. In that way, this question reduces to “what are the risks of reusing an encryption key?”, which is a well-understood problem.

The first problem is key distribution. Are you going to share the password with others? A shared password is at risk of exposure as you don’t control how the copy is handled.

The next risk is password guessing. If you choose a memorable password, it needs to be long enough to secure against brute force guessing. A PBKDF slows down attacks, but does not prevent them.

The next is key management. If you use the same password for multiple applications or systems, changing it becomes a difficult exercise in synchronization. And if it’s hard to change, you might not change it as often as you need.

Another is key compromise. If one shared password is leaked, the attackers have access to all data protected by that password. If you use different passwords, you limit the blast radius to only the one system.

The recommended best practice is to use one key for one single purpose, and to use as many keys as it takes to achieve this goal. Entire commercial key management systems are sold to help companies solve this problem. The more passwords you generate, the more likely you will probably turn to a password manager to meet your own requirements. And if your systems become so complex they reach this stage, why use passwords at all? Consider generating random keys directly, without the extra overhead of using passwords; you can still encrypt those keys in a centralized place using a master PBKDF derived key. HashiCorp vault is an open source tool that is designed to securely store secret data, you could use it to protect your keys at low cost.

| improve this answer | |

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.