Stabilize Payjoin V2 Implementation for payjoin-cli Beta

[DanGould]

Payjoin v2 BIP 77 spec employs RFC 9180 Hybrid Public Key Encryption (HPKE) for both Oblivious HTTP and end-to-end authenticated encryption between senders and receivers.

The BIP specified cryptographic dependencies are secp256k1-based DHKEM for HPKE, RFC 8439 ChaCha20Poly1305 AEAD, and HKDF-SHA256 since their cryptographic dependencies are already utilized by bitcoin software.

The existing hpke crate used for OHTTP uses other cryptographic primitives. The payjoin v2 implementation in this crate uses a secp256k1 hpke implementation defined here rather than the hpke crate for sender-receiver AEAD.

That's because the ohttp crate does not yet support secp256k1 DHKEM. Since payjoin is designed for bitcoin settings, using secp256k1 and especially the common libsecp256k1 crate would allow us to reduce dependency burden downstream.

Stabilizing the protocol implementation will require 3 steps

1. ✅ Enable Secp256k1 DHKEM and ChaCha20Poly1305 AEAD in the hpke crate

This has been implemented but only in an unstable-k256 branch https://github.com/rozbb/rust-hpke/tree/unstable-k256.

This is basically a proof of concept that we can't take full advantage of since it's not 1.63.0 MSRV.

2. ✅ Enable Secp256k1 DHKEM and ChaCha20Poly1305 AEAD in the hpke crate for ohttp

This is being tracked by #126

The underlying hpke change is rozbb/rust-hpke#52

Once we have an HPKE implementation it needs to be supported in our OHTTP implementation, too. This will be a breaking change for all Payjoin V2 implementations.

#354

3. Replace RustCrypto dependencies with those shared in the rust-bitcoin ecosystem, like the ✅ secp256k1 libsecp256k1 bindings crate.

Virtually all downstream bitcoin software uses libsecp256k1 library. It makes sense for us to try to either have that supported in the hpke crate or create a fork that relies on libsecp256k1. Since hpke is based on RustCrypto it makes more sense to me to ship a secp256k1-hpke fork. It may also make sense to use the same chacha20poly1305 rust implementation from rust-bitcoin or allow for a crypto provider since some operating systems now support it. Sha256 could come from bitcoin-hashes. Using common dependencies allows downstream software to reduce the size of their dependency tree for both for faster and smaller binary delivery and compile times as well as a reduced attack surface.

Our first iteration might just use secp256k1 in order to meet MSRV 1.63.0, and those after can include bitcoin-hashes with chacha20poly1305 and sha256. But if we can get a crate to support rust-secp256k1 and MSRV with different hash dependencies to start that is acceptable for our beta v2 feature. Then the protocol will be stable and we can chip away at the dependency tree.

4. Replace our jank V2 AEAD implementation with the secp256k1-hpke's standard one.

Deploying a standard HPKE protocol will allow the crate and implementation to be interoperable with other implementations which may crop up even if the underlying implementations of cryptographic primitives change.

Another option would be to write many tests showing that our protocol conforms with HPKE standards, but it would make more sense to combine our efforts with the better-reviewed-for-that-specific-purpose hpke crate.

#125 Can take place in parallel to #126.

#355

5. ✅ Decide on a URI encoding for payjoin params pj subdirectory and ohttp

(implement #298)

Base64Uri encoding, which we use as of now for these parameters, uses both upper and lowercase letters. Because of this it doubles the density of QR codes representing them. We could use another encoding like UR, since both are already properly serialized secp256k1 pubkey and OhttpKey configuration data blobs. Lightning invoices use bech32, but we don't have multiple fields to serialize in that format. In any case we need to finalize the encoding. It would also be wise to confirm that the way we're issuing subdirectories at the payjoin-directory server will not result in collisions.