Implement HKDF algorithm (RFC 5869) #355
Conversation
|
Fixed merge conflict due to 7e729bb. |
|
Just FYI, I just rebased the patches on master to fix a merge conflict caused by 3a3cb62. Also, I kept the actual implementation and the tests on two separate commits for easier review, but if you prefer I can squash them together. |
|
Heh, incidentally Travis just caught the fact that there still was an unresolved merge conflict, causing the build to fail. Fixed now :) |
|
Rebased again after the nptest thing (waiting for travis to finish, but everything seems ok). |
|
@richsalz is there any chance of this getting merged? It's been open for a while now. I think this should go into 1.1 so that we are going to be somewhat readier for the TLS 1.3 work afterwards. If it's a problem of "who's gonna maintain this?" than I'm of course available if that has any value. The code is also pretty simple (the algorithm itself is simple), it has documentation and tests as well (the vectors come from the RFC), but if I somehow can make things better to get this merged let me know. |
|
I just realised the patch needed to be updated to the new HMAC_CTX API, done now. |
|
I rebased this yet again, and adapted to yet another build system :) I'd really like to know if there's any interest in this at all though, so I can put my soul to rest and just stop rebasing this. Since at some point this will need to be implemented for TLS 1.3 anyway, I'd say better merge it now than have to re-implement it later. |
|
I am interested in this. Don't know if that puts your soul to rest or adds more unease. |
|
At least now I know I'm not doing this for nothing :) |
|
Can we expose a "simpler" EVP interface? Or not? |
|
We don't currently have an EVP interface that exposes this kind of functionality AFAICT, so it would need to be added. Note that for TLS 1.3 we'll probably want to call |
|
Not even faking it out with EVP ctrl options? Probably not. |
Well, that would probably make it more complicated instead of simpler :) I could see adding a generic KDF API, but e.g. PBKDF2 has very different use cases than HKDF and a different API as well (it has an iterations count argument), so it would still be quite awkward I think. |
|
yeah. let me see what Steve thinks. |
|
@richsalz @snhenson I've updated this to expose the FYI, I removed the |
|
Also, this doesn't expose the "extract and "expand" phases anymore, so there could be "loss of efficiency" in some cases, as the TLS 1.3 spec puts it, but it's probably very small. In any case it shouldn't be hard to expose my original API ( |
|
this looks good. you can add the docs now, or perhaps wait to see if others on the team have feedback for you. thanks! |
|
Re-added documentation. |
| EVP_PKEY_CTX *pctx; | ||
| unsigned char out[10]; | ||
| size_t outlen = sizeof(out); | ||
| pctx = EVP_PKEY_CTX_new_id(EVP_PKEY_HKDF, NULL); |
There was a problem hiding this comment.
Ok, fixed. FWIW most of the documentation page was copied from EVP_PKEY_TLS1_PRF.pod and adapted to HKDF.
|
+1 Nice job! |
|
@richsalz aaaaaaand done. Note that I had to make a few small changes to adjust to the new test suite, so a quick re-review may be needed. |
|
:) looks good. pushing for another review soon. |
This patch implements the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) as defined in RFC 5869. It is required to implement the QUIC and TLS 1.3 protocols (among others).
|
done! thanks. |
|
and ... @aacfb13 ... done! |
* Fix interop test suite due to BoringSSL update.
This PR implements the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) as defined in RFC 5869.
It is required to implement the QUIC and TLS 1.3 protocols (among others).