Generate k256 test vectors on secp

[DanGould]

No description provided.

[DanGould]

@spacebear21 I requested your review knowing that you're not familiar with this codebase. My main concern is whether or not you think this has major organizational problems. I'm confident the vectors it generates work in 3 separate implementations, 2 based on this rust-hpke codebase and one based on the hpke-rs codebase referenced in the MR history.

Does my (unimplemented) thinking to separate into a kat module with common functions and separate kat/test.rs to check vectors from kat/gen.rs that could be a callable binary to produce them, documented in the README make sense? Anything else that leaps out at you as unmanageable with an understanding that you're only doing a light review since you're not familiar with the codebase?

[spacebear21]

At a high level this seems reasonable to me. Nice work on getting those vectors ready.

I don't see any organizational issues with splitting up the kat module. I take it the goal is to eventually get secp256k1 support into the upstream rust-hpke, at which point we won't need to maintain a bespoke bitcoin-hpke codebase? Unless is there some other motivation for keeping this fork?

[DanGould]

I'd like to not have to maintain a fork, but I think most payjoin targets will already have chacha20poly1305, sha256, and secp256k1 available through bitcoin dependencies and our fork can depend on those same dependencies to reduce the size of the dep tree.

Perhaps it can all be upstream with feature gates to rust-hpke, but I'm not sure. It seems like that crate's minimum requirement for a main branch merge was to have an RFC specifying the DHKEM

[DanGould]

The only change post @spacebear21's comment was #[ignore]ing the test generation since the file is committed and only manual intervention is needed to generate vectors.