3 ms·
This is not an effective workaround. Without your suggestion, the length of encrypted packages is f(x), where x is the chosen plaintext, and f(x) happens to be
by nhaehnle 14y ago
This is not an effective workaround. Without your suggestion, the length of encrypted packages is f(x), where x is the chosen plaintext, and f(x) happens to be smaller if x correctly guesses one character of the secret.
With your suggestion, the length of encrypted packages is f(x) + E, where E is a random variable (noise) that does not depend on x.
Because of that, an attacker simply has to repeat the attack sufficiently many times to gather statistics on package lengths until there is one value of x for which packages are clearly shorter on average than for the rest. This is very similar to the type of sampling you would do in a timing attack.
So your suggestion does make the attack slightly more complicated, but qualitatively, the system remains broken.
- StavrosK 14y agoHow about padding to a multiple of X bytes?
- warp 14y agothen an attacker will pad it to be close the threshold of the multiplier. The difference between X multiples and X+1 multiples will still allow the attacker to determine the difference in compression size.
- yk 14y agoThe attacker controls at least part of the body such that he can select the length of the message. If the attacker pads his guess such that the total message length is N X+1, then for a successful guess the message length is NX and for a non successful one (N+1) * X. You would need too give the message a random length independent of the body to make this attack unfeasibly.
- smoyer 14y agoBut adding a random length, random comment within the body of your HTML might eliminate the correlation between a correct key character and compressed length.
- alanh 14y agoThat’s the same thing.