1. Is it fair to say a PBKDF is a specialization of KDF?

Sure. A PBKDF is a KDF, just one that uses a password/passphrase as the entropy source.

OTOH, a KBKDF (key-based KDF, if you want to call it that) is also a specialization of a KDF. A different specialization, which is why it may not be a good idea to treat them as a single thing.

2. Will a software interface that support the five parameters above be sufficient?

There are a couple of common parameters that are missing:

1. Many password hashing functions have a second cost parameter indicating how much memory will be used. (E.g. scrypt, most of those from the currently running Password Hashing Competition.)

2. Another relatively common parameter is a pepper. You can just include it as part of the salt if needed, but then the same is true for your context information parameter.

I also don't think your parameters, even with the above additions, are the best way to define such an interface.

For one, I don't think a salt should ever be left out, so I don't see why it should be optional.

For another, there is a significant difference in how a key derivation function is normally used, compared to how a password hash is used:

• With a key derivation function, you are going to need a key of a certain size as output.

• With a password hash it is useful to get an opaque return value that can be passed as the only additional parameter into a verification routine:

   verify(password, combined_hash) 

  (Cf. Modular Crypt Format.)

  This way the iteration count, salt, etc. is easily stored with the hash, and different hashed can have different parameters, allowing one to upgrade the strength with time as attackers' computational power increases.

1. Is it fair to say a PBKDF is a specialization of KDF?

Sure. A PBKDF is a KDF, just one that uses a password/passphrase as the entropy source.

OTOH, a KBKDF (key-based KDF, if you want to call it that) is also a specialization of a KDF. A different specialization, which is why it may not be a good idea to treat them as a single thing.

2. Will a software interface that support the five parameters above be sufficient?

There are a couple of common parameters that are missing:

1. Many password hashing functions have a second cost parameter indicating how much memory will be used. (E.g. scrypt, most of those from the currently running Password Hashing Competition.)

2. Another relatively common parameter is a pepper. You can just include it as part of the salt if needed, but then the same is true for your context information parameter.

I also don't think your parameters, even with the above additions, are the best way to define such an interface.

For one, I don't think a salt should ever be left out, so I don't see why it should be optional.

For another, there is a significant difference in how a key derivation function is normally used, compared to how a password hash is used:

• With a key derivation function, you are going to need a key of a certain size as output.

• With a password hash it is useful to get an opaque return value that can be passed as the only additional parameter into a verification routine:

   verify(password, combined_hash) 

  (Cf. Modular Crypt Format.)

  This way the iteration count, salt, etc. is easily stored with the hash, and different hashed can have different parameters, allowing one to upgrade the strength with time as attackers' computational power increases.