Implement HKDF

[3a6db5]

I wanted to use Graviola in a personal toy project and noticed the crate didn’t include HKDF, so I took the time to implement it.

I drew strong inspiration from ring::hkdf, both in the implementation and the API.

However, I chose not to implement extract and expand as methods on Salt and Prk. Instead, they are provided as free functions in the module (hkdf::extract and hkdf::expand). I find this approach more intuitive. One potential downside is that the result of extract (Prk) is not tied to a specific hashing algorithm. ring avoids this issue by binding the Prk to the algorithm at extraction time. From my understanding, this does not create any crypto weakness.

Questions/Considerations

1. I’m not a big fan of the Prk enum. It feels a bit hacky.
2. I’m unsure whether the salt parameter of hkdf::extract should be optional. According to RFC 5869, "the use of salt adds significantly to the strength of HKDF" and "designers of applications are therefore encouraged to provide salt values." Making the parameter non‑optional would force users to supply a salt (similar to how ring behaves).
3. Should I add the same SPDX‑License‑Identifier header in hkdf.rs? Done in 9e040c7.
4. hkdf::expand will panic if okm.len() > 255 * hash_len. Maybe we want to return an error instead. In my opinion, users will most often call this function with a fixed‑length array, so an error should be rare and panicking seems appropriate. Note that RustCrypto's and ring's APIs return a Result.

Please, feel free to comment on any of these points.

---

• Add benchmarks.
• Increase coverage.

[codspeed-hq]

CodSpeed Performance Report

Merging #110 will not alter performance

_{Comparing 3a6db5:3a6dbc-hkdf (8357ce9) with main (ce148a2)}

Summary

✅ 143 untouched
🆕 16 new

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
🆕	aws-lc-rs[1 * HashLen]	N/A	15.8 µs	N/A
🆕	aws-lc-rs[255 * HashLen]	N/A	434.9 µs	N/A
🆕	graviola[1 * HashLen]	N/A	15.7 µs	N/A
🆕	graviola[255 * HashLen]	N/A	809.4 µs	N/A
🆕	ring[1 * HashLen]	N/A	12.1 µs	N/A
🆕	ring[255 * HashLen]	N/A	423.2 µs	N/A
🆕	rustcrypto[1 * HashLen]	N/A	17 µs	N/A
🆕	rustcrypto[255 * HashLen]	N/A	607.9 µs	N/A
🆕	aws-lc-rs[1 * HashLen]	N/A	19.3 µs	N/A
🆕	aws-lc-rs[255 * HashLen]	N/A	565.1 µs	N/A
🆕	graviola[1 * HashLen]	N/A	14.2 µs	N/A
🆕	graviola[255 * HashLen]	N/A	577.7 µs	N/A
🆕	ring[1 * HashLen]	N/A	14.7 µs	N/A
🆕	ring[255 * HashLen]	N/A	560.2 µs	N/A
🆕	rustcrypto[1 * HashLen]	N/A	16.5 µs	N/A
🆕	rustcrypto[255 * HashLen]	N/A	749 µs	N/A

[codecov]

Codecov Report

❌ Patch coverage is 99.45946% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 99.14%. Comparing base (8ef30ca) to head (8357ce9).
⚠️ Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
graviola/src/test.rs	66.66%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##             main     #110    +/-   ##
========================================
  Coverage   99.14%   99.14%            
========================================
  Files         171      172     +1     
  Lines       39074    39258   +184     
========================================
+ Hits        38738    38921   +183     
- Misses        336      337     +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[3a6db5]

I added the hex-literal dev-dependency and used it to write the unit test inputs in the same format as the RFC test vectors. Let me know if you’d prefer to avoid this extra dependency (it has no subdependencies).

[ctz]

Sorry for not looking at this yet. But I think HKDF is a reasonable thing to live here, so I will review this soon.