rust-payjoin icon indicating copy to clipboard operation
rust-payjoin copied to clipboard

Remove pad plaintext from hpke

Open benalleng opened this issue 10 months ago • 6 comments

We had a function that checked and then padded the length of the plaintext when running message encryption. Instead we should use a fixed array length and return an error if the message is of the wrong length.

I mentioned this is related to #402 but really that issue only has to do with public api calls

benalleng avatar Feb 04 '25 19:02 benalleng

Pull Request Test Coverage Report for Build 17480395424

Details

  • 77 of 91 (84.62%) changed or added relevant lines in 4 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.007%) to 85.947%

Changes Missing Coverage Covered Lines Changed/Added Lines %
payjoin/src/core/send/v2/mod.rs 60 62 96.77%
payjoin/src/core/receive/error.rs 0 6 0.0%
payjoin/src/core/receive/v2/mod.rs 3 9 33.33%
<!-- Total: 77 91
Totals Coverage Status
Change from base Build 17446213698: 0.007%
Covered Lines: 8238
Relevant Lines: 9585

💛 - Coveralls

coveralls avatar Feb 05 '25 14:02 coveralls

@benalleng was there something blocking this PR?

spacebear21 avatar Aug 21 '25 13:08 spacebear21

I need to come back to this, I totally forgot it existed. I think the issue I was having had to do with trying to simplify this down to an array with some dynamic length while also trying to stay true to this original comment from #405. https://github.com/DanGould/rust-payjoin/blob/4998108a1ac86bad14cdb9b2332a629f2e23b7e4/payjoin/src/hpke.rs#L247-L255

benalleng avatar Aug 21 '25 15:08 benalleng

A follow-up question, where is an appropriate place to actually pad this message to equal the array length of the PADDED_PLAINTEXT_A/B_LENGTH

benalleng avatar Aug 25 '25 00:08 benalleng

A follow-up question, where is an appropriate place to actually pad this message to equal the array length of the PADDED_PLAINTEXT_A/B_LENGTH

I'm not sure I actually understand the motivation for this PR. To me encrypt_message_a/b does seem like the appropriate place to apply padding to a variable length message. Is there an issue that prompted this and provides more context?

spacebear21 avatar Aug 25 '25 21:08 spacebear21

I guess the logical place to pad the message is right before encrypt_message_a/b are called in the respective create_x_request functions.

spacebear21 avatar Aug 29 '25 17:08 spacebear21