Incorrect usage of the HMAC APIs

[mattcaswell]

This talk discusses a security attack which may result if the HMAC APIs are used incorrectly:

https://www.youtube.com/watch?v=hYDD_rI_8tU

The issue occurs if an application developer makes calls in this order:

HMAC_Init_ex()
HMAC_Update()
HMAC_Final()
HMAC_Update()
HMAC_Final()

i.e. if an HMAC_CTX is reused to "incrementally" calculate the HMAC of a message consisting of multiple fragments, but without calling HMAC_Init_ex() again, before calling update and then final.

As noted above this is incorrect usage of the API, but the APIs do not protect you from this foot gun. Should they?

It looks to me like we don't do a check to protect against this in the EVP_MAC APIs either (and probably not with other init/update/final APIs). Should we?

[paulidale]

The paper Unintended Features of APIs: Cryptanalysis of Incremental HMAC is available on the conference site.

[kaduk]

As noted above this is incorrect usage of the API, but the APIs do not protect you from this foot gun. Should they?

I believe this is "yes", though there are perhaps arguments to be made about API stability.
I thought that we had a couple existing APIs that did enforce single-use via Final() (maybe EVP_MD_CTX? Though the code is not a clear example), as some precedent for this being a good idea.

It looks to me like we don't do a check to protect against this in the EVP_MAC APIs either (and probably not with other init/update/final APIs). Should we?

This seems to be pretty unambiguously "yes".

[kroeckx]

Since EVP_MAC is a new and as yet unreleased API, I think we should prevent the user from doing that with EVP_MAC.

[beldmit]

I think we should have some checks preventing bad order of operations in this and in some other cases.

[kroeckx]

APIs like EVP_VerifyFinal() and EVP_DigestVerifyFinal() document that calling Update after Final is possible. I assume they don't have the same problem.

[mattcaswell]

APIs like EVP_VerifyFinal() and EVP_DigestVerifyFinal() document that calling Update after Final is possible. I assume they don't have the same problem.

Until I saw issue #13342 I had been thinking that we should incorporate checks everywhere for all APIs that ban this type of calling. The Verify APIs confuse this picture somewhat.

[mattcaswell]

Until I saw issue #13342 I had been thinking that we should incorporate checks everywhere for all APIs that ban this type of calling. The Verify APIs confuse this picture somewhat.

I also wonder whether we have tests for this way of using the Verify APIs and whether it even still works with the provider model.

[levitte]

Something to be noted is that EVP_DigestFinal() clears the context data when it's done producing the output, at least in 1.1.1. In 3.0, we're leaving that to the provider implementation... and at least most of our implementations do that clearing (for pretty obvious reasons, the SHA3 one does not)

It seems that HMAC_Final() doesn't do this sort of clearing... and maybe it should?

EDIT: ... HMAC_Final() calls EVP_DigestFinal_ex(), so I may not have thought this through enough. It makes me wonder what kind of random output is expected from the second Update+Final call...