Repository navigation
Test that Request Creation can use cloned OhttpKeys to remove &mut #1084
Description
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.
Activity
[-]Test that Request Creation can use cloned OhttpContext to remove &mut[/-][+]Test that Request Creation can use cloned OhttpKeys to remove &mut[/+]arminsabouri commentedon Sep 16, 2025
I can confirm that distinct calls to
from_configcreate hpke sender contexts that are different. I wrote a test that creates two different contexts using the sameKeyConfigAdditionally, the recepient public key /
KeyConfigbeing 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 commentedon Sep 16, 2025
&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 commentedon Sep 17, 2025
Created an upstream martinthomson/ohttp#83 PR
Closed by #1085
DanGould commentedon Sep 18, 2025
fwict #1085 doesn't test this, it just assumes it's a non issue. No reason to test?
nothingmuch commentedon Sep 18, 2025
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