KDF Mode/Revision Formatting

[abkarcher]

Hello!

When KMAC mode was added to SP800-108 rev1 and subsequently to acvp, it used a different mode and revision from the other SP800-108 modes. (SP800-108 just used KDF revision 1.0, this uses KDF mode KMAC revision SP800-108r1). Will the original KDF108 counter/feedback/double pipeline modes be updated to use this new style of registration at this point? Can we expect new KDFs to follow this style in the future? (Looks like the updated TLS kdfs also follow this style).

It does have a small impact on how we define the lines between algorithms in our client. Right now the original 3 modes of KDF from SP800-108 all fall under the same algorithm in libacvp, but the addition of the KMAC mode makes it a little messy. We may end up splitting all of the SP800-108 modes out into their own if KDFs will follow this pattern moving forward.

On a semi-related note, If updates to testing methodology occur for KDFs following this style, how would the update in testing methodology be reflected in the revision? For example, SHA3 was updated from 1.0 to 2.0 when the tests were updated. What would it look like for something using an SP doc as the revision? Or is it safe to assume the methodology will not change unless a new SP revision is released? This also applies to some other ciphers, like ones referencing FIPS186-4/5 as a revision.

Thanks,
Andrew

[livebe01]

(Tagging @celic b/c he's more of an authority on this than I am)

Hi Andrew,

Good observation and points.

I think that, when Chris was writing the KMAC mode, he considered refactoring the counter/feedback/double pipeline mode so that they could be accessed via a similar style. That said, I don't know if or when we may do that.

I think that using the standard for the revision field has some virtue. It provides a logical way to differentiate between testing differences between different versions of a standard. That said, you have a point with your semi-related note. I'm not 100% on how that scenario would be handled.

Ben