Remove pad plaintext from hpke
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
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 | |
|---|---|
| Change from base Build 17446213698: | 0.007% |
| Covered Lines: | 8238 |
| Relevant Lines: | 9585 |
💛 - Coveralls
@benalleng was there something blocking this PR?
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
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
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?
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.