Missing KDFs

[tarcieri]

This is a tracking issue for KDF algorithms we should potentially implement.

Please leave a comment with your requests!

[touilleMan]

Hi,

It seems the kdf algo from libsodium is missing.

It would be pretty trivial to add it given it's basically a bit of cooking on top of blake2b:

    pub fn kdf_blake2b_derive_from_key::<OutSize>(subkey_id: u64, context: &[u8;8], key: &GenericArray<u8, U32>) -> [u8;OutSize] {
        let mut personal: [u8;16] = [0u8;16];
        personal[..8].copy_from_slice(context);

        let mut salt: [u8;16] = [0u8;16];
        salt[..8].copy_from_slice(&subkey_id.to_le_bytes());

        Blake2bMac<OutSize>::new_with_salt_and_personal(&key, &salt, &personal)
          .expect("subkey has always a valid size")
          .finalize().into()
}

[nemynm]

Hello,
I would propose ANSI-X9.63-KDF. I have opened a dedicated issue #101.

[TheBestTvarynka]

KBKDF from NIST SP 800-108 is missing. It would be nice to have it implemented. This KDF is used in Microsoft protocols for key derivation. For example, https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gkdi/5d373568-dd68-499b-bd06-a3ce16ca7117:

KDF(HashAlg, KI, Label, Context, L) — denotes an execution of the [SP800-108] KDF in counter mode ([SP800-108] section 5.1) by using the Hash Message Authentication Code (HMAC) specified in [FIPS198-1].

I found #87, but it's a draft and hasn't had any updates for the last year.

Do you accept external contributions? Maybe I'll consider implementing it in the future.

[tarcieri]

cc @baloo

[baloo]

@TheBestTvarynka Feel free to take over or redo the PR :)

This is something I hoped to get back to, but I haven't got time to yet. My use-case for it was for TPM activate credential with RSA keys.
I think the implementation is correct, but I wanted to get tests going.

I got bogged down by the CAVS test vectors. I implemented them as a procmacro that will generate rust test code, but that ended being the wrong approach, it's too slow to iterate.

[TheBestTvarynka]

Feel free to take over or redo the PR :)

I want to take over the KBKDF implementation.

@baloo, I already read the specification and your draft PR (#87). The code looks good but I have a few questions. Where is the best place to ask these questions? I'll implement the rest and address all comments.

I got bogged down by the CAVS test vectors. I implemented them as a procmacro that will generate rust test code, but that ended being the wrong approach, it's too slow to iterate.

I looked through those test vectors. Are we going to turn all of them into tests? You wanted to do testing like in the hkdf crate. Am I right?

Thank you!

[baloo]

Feel free to take over or redo the PR :)

I want to take over the KBKDF implementation.

@baloo, I already read the specification and your draft PR (#87). The code looks good but I have a few questions. Where is the best place to ask these questions? I'll implement the rest and address all comments.

I guess open a Draft PR and ping me in there?

I got bogged down by the CAVS test vectors. I implemented them as a procmacro that will generate rust test code, but that ended being the wrong approach, it's too slow to iterate.

I looked through those test vectors. Are we going to turn all of them into tests? You wanted to do testing like in the hkdf crate. Am I right?

I didn't look at hkdf at the time, but the hkdf is a much more sensible approach.

I made macros that generated rust-code from the vectors, hdfk just reads the vectors and treat them as data. (the data are embedded in the tests through include_bytes but this is treated by the compiler as a single piece of blob (that still inflates the binary size, but this is tests we don't care), where my approach generated code which needed to be compiled, and slowed down everything ... that was an idiotic approach).

[TheBestTvarynka]

Thank you. I'm going to start working on it