During encryption, the code in this crate currently selects a random integer between zero and the allowed record size, and adds that many bytes of padding to the plaintext.
It's my understanding that adding random padding isn't all that helpful in practice, because if your adversary collects enough samples they can statistically filter out the noise. IMHO we should either do something better here, or do what the Desktop code does and not pad at all because we don't have enough information about the usage context to do it well.
RFC 8188 Section 4.8 has some commentary on padding, and notes that "Developing a padding strategy is difficult". It lists three common strategies, all of which seem tractable and none of which are "add a random amount of padding":
- padding to a small set of fixed lengths
- padding to multiples of a value
- padding to powers of 2
(That section also says "distributing non-padding data across records is recommended to avoid leaking size information", which is something that this crate does do, and which seems worth keeping).
I propose that we change the current padding calculation to round up the plaintext size to multiples of a fixed size; for the sake of argument let's say multiples of 128 bytes. If that doesn't seem worth the effort, then I propose that we remove the padding entirely in the interests of simplicity.
I'll reach out to @martinthomson to see if he'd like to weigh in on the particulars here.
During encryption, the code in this crate currently selects a random integer between zero and the allowed record size, and adds that many bytes of padding to the plaintext.
It's my understanding that adding random padding isn't all that helpful in practice, because if your adversary collects enough samples they can statistically filter out the noise. IMHO we should either do something better here, or do what the Desktop code does and not pad at all because we don't have enough information about the usage context to do it well.
RFC 8188 Section 4.8 has some commentary on padding, and notes that "Developing a padding strategy is difficult". It lists three common strategies, all of which seem tractable and none of which are "add a random amount of padding":
(That section also says "distributing non-padding data across records is recommended to avoid leaking size information", which is something that this crate does do, and which seems worth keeping).
I propose that we change the current padding calculation to round up the plaintext size to multiples of a fixed size; for the sake of argument let's say multiples of 128 bytes. If that doesn't seem worth the effort, then I propose that we remove the padding entirely in the interests of simplicity.
I'll reach out to @martinthomson to see if he'd like to weigh in on the particulars here.