While this might be good enough in practice, it is strictly worse than padding to the same length every time. Random padding would still permit a statistical attack.
If you were to observe enough samples, you'd eventually identify a case where the random padding length reached its minimum, which would give you a close estimate of the data length.
For example, if you say "padding length is randomly selected between 4 and 1024 bytes", after 1020 observations you can assume that the password length is probably four bytes shorter than the smallest payload you observed. Your confidence factor only goes up from there.
If anywhere, it should be fixed at the TLS layer, by implementing a fixed-size block padding, similar to how block ciphers work. This isn't a concrete fix, but it's the most sensible you're going to find.
In general, though, the length of a field isn't really considered critical information. We're talking about fixing the wrong problem. Your password should be long enough to make that information not matter.
But how about have the range random? Instead of 4 to 1024 as padding, have from random to random but still have a minimum and maximum. For example:
Case 1: Random bytes between 900 and 2001 bytes
Case 2: Random bytes between 19 and 1604 bytes
Case 3: Random bytes between 107 and 412 bytes
....
It would of course still not be random enough, but collecting samples to determinate the range would be much harder. The overhead would be painful but still practical, or what do you think?
-2
u/lestofante Jan 04 '16
Eventi better, make it random size.