Test that Request Creation can use cloned OhttpKeys to remove &mut

[DanGould]

Request creation using ohttp_encapsulate require a &mut OhttpKeys. I believe HpkeS that's created in ohttp::ClientRequest::from_config(ohttp_keys)?, where ohttp_keys is &mut, incorporates randomness so that this mutation does not need to be saved each time a request is created. If it does need to be saved, we need to make sure we're saving it.

Write a test to confirm that distinct calls to ClientRequest::from_config are different (indistinguishable, really) so that subsequent requests, especially requests between persisted resumption, are not able to be correlated.

Document the result, and potentially allow those state machine create request methods to take an immutable self or &self that clones OhttpKeys to make this design obvious.

[arminsabouri]

I can confirm that distinct calls to from_config create hpke sender contexts that are different. I wrote a test that creates two different contexts using the same KeyConfig

Additionally, the recepient public key / KeyConfig being mut seems to unneeded upstream aswell. Removing mut seems to have no impact. Tests all pass.

We can improve out pub interface by removing the mut constrain on keyConfig and clone(). At the same time we should upstream a commit to remove mut.

[nothingmuch]

&mut isn't really necessary upstream either as far as I can tell, but the bitcoin_ohttp crate's repo is bitrotted for me so i can't verify that payjoin/ohttp#5

[arminsabouri]

Created an upstream martinthomson/ohttp#83 PR

Closed by #1085

[DanGould]

fwict #1085 doesn't test this, it just assumes it's a non issue. No reason to test?

[nothingmuch]

wdym test? the ohttp crate does not actually modify that struct, and that struct only contains the public keys (it's not like the hpke state that contains a shared secret that gets ratcheted for the reply)

edit: fwiw arminsabouri/ohttp@3ba40b3 is no more a test that this is secure than the fact that it compiles, but it would be very bad if security required state management, that is not how hpke is specced, and the ohttp crate's code confirms that this is not actually mutated (it's just passed to hpke::setup_sender which takes an immutable &Kem::PublicKey), i suspect it's an oversight that came about because of the NSS implementation