Return to Answer

Yes, you could use PBKDF2 for this.

You can use an iteration count of 1 as the master key will already contain 256 bits of entropy: that's plenty, you don't need any strengthening for that.

So you should try and configure PBKDF2 using HMAC-SHA256 or HMAC-SHA512 as PRF. Note that the standard indicates SHA-1 as default, so that's probably what is used if you don't configure it with a different secure hash or HMAC. It seems however impossible to configure Rfc2898DeriveBytes with SHA-256. That means that the key strength may be diminished somewhat as SHA-1 is configured to provide no more than 160 bits of security.

Note that normally you should not use more output from PBKDF2 than the hash size as it provides an advantage to an attacker. This is however inconsequential because the high amount of entropy in the master key puts the attacker at a pretty strong disadvantage in the first place.

Input:

• P: the masterkey in bytes (instead of the password)
• S: the derivation data, possibly prefixed by a salt (included with the ciphertext, one salt should suffice per set of keys)
• c: the iteration count, set to 1
• dkLen: 32 (the size of the derived key or secret in octets)

You could for instance use an 8 byte salt, followed by the encoding of the ASCII encoded strings "EncKey" and "AuthKey". You may also want to include some ID, especially if you want to establish keys between two parties (for two way communication).

The salt isn't really necessary, it's optional for HKDF as well.

Implementing HKDF is indeed not that hard, but be sure to test it plenty if you decide to go that route.

One advantage of choosing HKDF is that HMAC expects a key instead of a password. So you probably could use a key container with HMAC while that would not be possible for PBKDF2.

Your choice.

Yes, you could use PBKDF2 for this.

You can use an iteration count of 1 as the master key will already contain 256 bits of entropy: that's plenty, you don't need any strengthening for that.

So you should try and configure PBKDF2 using HMAC-SHA256 or HMAC-SHA512 as PRF. Note that the standard indicates SHA-1 as default, so that's probably what is used if you don't configure it with a different secure hash or HMAC. It seems however impossible to configure Rfc2898DeriveBytes with SHA-256. That means that the key strength may be diminished somewhat as SHA-1 is configured to provide no more than 160 bits of security.

Note that normally you should not use more output from PBKDF2 than the hash size as it provides an advantage to an attacker. This is however inconsequential because the high amount of entropy in the master key puts the attacker at a pretty strong disadvantage in the first place.

Input:

• P: the masterkey in bytes (instead of the password)
• S: the derivation data, possibly prefixed by a salt (included with the ciphertext, one salt should suffice per set of keys)
• c: the iteration count, set to 1
• dkLen: 32 (the size of the derived key or secret in octets)

You could for instance use an 8 byte salt, followed by the encoding of the ASCII encoded strings "EncKey" and "AuthKey". You may also want to include some ID, especially if you want to establish keys between two parties (for two way communication).

The salt isn't really necessary, it's optional for HKDF as well.

Implementing HKDF is indeed not that hard, but be sure to test it plenty if you decide to go that route; in the end this is your choice.

[EDIT: removed HMAC using key for HKDF, IKM is put in HMAC as message, not as key]

Yes, you could use PBKDF2 for this.

As SEJPM indicated, it is however not a good idea to generate a large amount of output: you don't want to go over the output of the configured hash. You can use an iteration count of 1 as the master key will already contain 256 bits of entropy: that's plenty, you don't need any strengthening for that.

So you could configure PBKDF2 using HMAC-SHA256 or HMAC-SHA512 as PRF. Note that the standard indicates SHA-1 as default, so that's probably what is used if you don't configure it with a different secure hash or HMAC.

Input:

• P: the masterkey in bytes (instead of the password)
• S: the derivation data, possibly prefixed by a salt (included with the ciphertext, one salt should suffice per set of keys)
• c: the iteration count, set to 1
• dkLen: 32 (the size of the derived key or secret in octets)

You could for instance use an 8 byte salt, followed by the encoding of the ASCII encoded strings "EncKey" and "AuthKey". You may also want to include some ID, especially if you want to establish keys between two parties (for two way communication).

The salt isn't really necessary, it's optional for HKDF as well.

Implementing HKDF is indeed not that hard, but be sure to test it plenty if you decide to go that route.

One advantage of choosing HKDF is that HMAC expects a key instead of a password. So you probably could use a key container with HMAC while that would not be possible for PBKDF2.

Your choice.

PS I cannot find any way to configure Rfc2898DeriveBytes with SHA-256. It may be stuck in a time-hole. So that's another reason to choose HKDF (or, if you can find it, another implementation of PBKDF2).

Yes, you could use PBKDF2 for this.

You can use an iteration count of 1 as the master key will already contain 256 bits of entropy: that's plenty, you don't need any strengthening for that.

So you should try and configure PBKDF2 using HMAC-SHA256 or HMAC-SHA512 as PRF. Note that the standard indicates SHA-1 as default, so that's probably what is used if you don't configure it with a different secure hash or HMAC. It seems however impossible to configure Rfc2898DeriveBytes with SHA-256. That means that the key strength may be diminished somewhat as SHA-1 is configured to provide no more than 160 bits of security.

Note that normally you should not use more output from PBKDF2 than the hash size as it provides an advantage to an attacker. This is however inconsequential because the high amount of entropy in the master key puts the attacker at a pretty strong disadvantage in the first place.

Input:

• P: the masterkey in bytes (instead of the password)
• S: the derivation data, possibly prefixed by a salt (included with the ciphertext, one salt should suffice per set of keys)
• c: the iteration count, set to 1
• dkLen: 32 (the size of the derived key or secret in octets)

You could for instance use an 8 byte salt, followed by the encoding of the ASCII encoded strings "EncKey" and "AuthKey". You may also want to include some ID, especially if you want to establish keys between two parties (for two way communication).

The salt isn't really necessary, it's optional for HKDF as well.

Implementing HKDF is indeed not that hard, but be sure to test it plenty if you decide to go that route.

One advantage of choosing HKDF is that HMAC expects a key instead of a password. So you probably could use a key container with HMAC while that would not be possible for PBKDF2.

Your choice.

Yes, you could use PBKDF2 for this.

As SEJPM indicated, it is however not a good idea to generate a large amount of output: you don't want to go over the output of the configured hash. You can use an iteration count of 1 as the master key will already contain 256 bits of entropy: that's plenty, you don't need any strengthening for that.

So you could configure PBKDF2 using HMAC-SHA256 or HMAC-SHA512 as PRF.

Input:

• P: the masterkey in bytes (instead of the password)
• S: the derivation data, possibly prefixed by a salt (included with the ciphertext, one salt should suffice per set of keys)
• c: the iteration count, set to 1
• dkLen: 32 (the size of the derived key or secret in octets)

You could for instance use an 8 byte salt, followed by the encoding of the ASCII encoded strings "EncKey" and "AuthKey". You may also want to include some ID, especially if you want to establish keys between two parties (for two way communication).

The salt isn't really necessary, it's optional for HKDF as well.

Note: implementing HKDF is indeed not that hard, but be sure to test it plenty if you decide to go that route.

One advantage of choosing HKDF is that HMAC expects a key instead of a password. So you probably could use a key container with HMAC while that would not be possible for PBKDF2.

Your choice.

Yes, you could use PBKDF2 for this.

As SEJPM indicated, it is however not a good idea to generate a large amount of output: you don't want to go over the output of the configured hash. You can use an iteration count of 1 as the master key will already contain 256 bits of entropy: that's plenty, you don't need any strengthening for that.

So you could configure PBKDF2 using HMAC-SHA256 or HMAC-SHA512 as PRF. Note that the standard indicates SHA-1 as default, so that's probably what is used if you don't configure it with a different secure hash or HMAC.

Input:

• P: the masterkey in bytes (instead of the password)
• S: the derivation data, possibly prefixed by a salt (included with the ciphertext, one salt should suffice per set of keys)
• c: the iteration count, set to 1
• dkLen: 32 (the size of the derived key or secret in octets)

You could for instance use an 8 byte salt, followed by the encoding of the ASCII encoded strings "EncKey" and "AuthKey". You may also want to include some ID, especially if you want to establish keys between two parties (for two way communication).

The salt isn't really necessary, it's optional for HKDF as well.

Implementing HKDF is indeed not that hard, but be sure to test it plenty if you decide to go that route.

One advantage of choosing HKDF is that HMAC expects a key instead of a password. So you probably could use a key container with HMAC while that would not be possible for PBKDF2.

Your choice.

PS I cannot find any way to configure Rfc2898DeriveBytes with SHA-256. It may be stuck in a time-hole. So that's another reason to choose HKDF (or, if you can find it, another implementation of PBKDF2).