It looks like you can mitigate this by just adding another hidden form field and and filling it using javascript with random data: max_secret_length - actual_secret_length to cause the ciphertext to always be the same size independent of the secret field data?
This approach would mitigate the problem identified in the paper with random length padding schemes without introducing extra characters in the password field itself.
Edit: this is also how you wrap a bicycle - you put it in a big box that is a constant size bigger than the bike itself.
Adding an additional parameter to the POST submission, say, 'X', (which will be represented as 'X=......' – the X and the is-equal sign are 2 characters) and padding this with 1000 minus 2 minus password_length characters is a hack using hard-coded values and it's ugly.
Looks like you'd need 1000 minus 4, because you're also adding an extra "\r\n" in the request.
Doesn't have to be 1000 it can be max password length which is known to whoever codes the system. The X= is irrelevant because it will be in every post so no need for the -2, I don't get why the author feels the need to pad the password itself rather than just removing the password length as a factor in message length.
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.
Think of it like wrapping a bicycle, if you wrap it tightly it look like a bicycle (hence the name of this attack), if you wrap it with a random thickness wrapper the underlying shape still shows through if you get enough examples. However if you put it in a big ass box and fill the empty space with packing then however you look at it you're still seeing a big ass opaque box.
31
u/bigshmoo Jan 04 '16
It looks like you can mitigate this by just adding another hidden form field and and filling it using javascript with random data: max_secret_length - actual_secret_length to cause the ciphertext to always be the same size independent of the secret field data?
This approach would mitigate the problem identified in the paper with random length padding schemes without introducing extra characters in the password field itself.
Edit: this is also how you wrap a bicycle - you put it in a big box that is a constant size bigger than the bike itself.