briansmith
Add hkdf::Prk::expand_to_secret()
Thanks for this. This was in fact the exact type signature that I had originally given to Prk::expand() but for some reason it didn't work...I think rustc's type inference didn't work as well for the combined function (like you have it here) vs. the separate steps (as expand currently is in the current source). Did you run into this yourself?
Yes, I ended up incorporating something like this in Quinn:
https://github.com/djc/quinn/blob/master/quinn-proto/src/crypto/ring.rs#L238
Did you run into this yourself?
Sorry if I wasn't clear. What I mean is, did you find that your new function failed to work because of type inference problems, or did you find that there were no type inference problems in your usage, or something in between?
Also, since Quinn is based on Rustls, IMO Rustls should just expose an API that makes all that Quinn code unnecessary. Quinn shouldn't be doing HKDF at all, AFAICT.
It took me a while to figure out the correct incantation, so it would be nice if that could live in ring. Especially since it took me quite some time to grok how to use the current API, and this new method makes it clearer how the pieces fit together.
@ctz took the opinion back when I started that he wanted rustls to know as little as possible QUIC-specific stuff, but maybe we ought to reconsider that position.
@ctz took the opinion back when I started that he wanted rustls to know as little as possible QUIC-specific stuff, but maybe we ought to reconsider that position.
Off-topic, but I think Rustls would actually be simpler if it did everything related to key derivation for QUIC, even not considering how much simpler Quinn would be. Rustls already has duplicate code for QUIC- and non-QUIC- code paths. I suggest making a Rustls PR so we can see how much better Rustls would get.
It took me a while to figure out the correct incantation, so it would be nice if that could live in ring. Especially since it took me quite some time to grok how to use the current API, and this new method makes it clearer how the pieces fit together.
Oh, I 100% agree. My point was that I implemented the harder-to-understand API because the easier-to-understand API didn't work as well due to type inference issues. I am wondering if you found that to be the case too, or if the stuff I was trying to do before was an anomaly. I'll double-check when I have some time.
Oh, I 100% agree. My point was that I implemented the harder-to-understand API because the easier-to-understand API didn't work as well due to type inference issues. I am wondering if you found that to be the case too, or if the stuff I was trying to do before was an anomaly. I'll double-check when I have some time.
IIRC rustc still can't figure out the return type of my hkdf_expand() method unless the target binding is clearly typed (which ends up usually being the case for my code). Is that what you mean? "type inference issues" can be different kinds of things in my experience.
@briansmith are you still interested in this? If yes, does it need any further work?
@djc Yes, I think it would be good to have this. It isn't being tested in hkdf_tests, which is the main blocker that I see.
I've updated the hkdf_tests() to use expand_to_secret() directly. Since hkdf_output_len_tests() still exercise the separate expand().into() idiom, this seems like a decent way to get coverage for this.
Going to close this since, in retrospect, the HKDF API needs to be revamped well beyond this step.