Question about opdata01 padding
Hi,
i have a question about the padding scheme you are using for opdata01. In the description of the file format you say:
The plaintext is padded using the following scheme.
If the size of the plaintext is an even multiple of the block size then 1 block of random data is prepended to the plaintext. Otherwise, between 1 and 15 (inclusive) bytes of random data are prepended to the plaintext to achieve an even multiple of blocks.
What I do not understand: why do you add padding when the plaintext length is an even multiple of the block size? Since the plaintext size is known, it seems unnecessary to me.
Greetings,
Johannes
Comments
-
What I do not understand: why do you add padding when the plaintext length is an even multiple of the block size? Since the plaintext size is known, it seems unnecessary to me.
That is an excellent question, @johannesauer.
There are reasons, just not good reasons.
First of all, our whole padding scheme is unnecessary given that we use an Encrypt-then-MAC construction around the CBC mode encryption. We would have been fine with standard CBC padding. So what you see is the result of accidents of history. We were working on two defenses against CBC padding oracle attacks. One was to use Encrypt-then-MAC and the other was to having random data in the pad.
When developing the custom padding scheme, we tried to keep as close to standard padding (which did need to extra block) while changing only the parts of it that made standard padding dangerous. So the extra block remained. Once we had Encrypt-then-MAC we could have (and probably should have) ditched our custom padding. Instead we left it in (because it was already chunks of our code), but we stopped working on it, and so never got around to the obvious optimization.
Now we just use GCM every where. So we neither need to roll our own Encrypt-then-MAC scheme nor have a funky CBC padding scheme. We can use standards and standard libraries to give us encryption that is safe from chosen ciphertext attacks.
So the reasons are a confluence of historical accident instead of clear design reasons.
0 -
Thanks for the comprehensive answer, @jpgoldberg.
This leads to another question: you say you wanted to avoid the possibility of CBC padding oracle attacks (which Encrypt-then-MAC indeed does prevent).
My question: why do you worry about these kind of attacks? All encryption/decryption should happen on the client - so why do you care about side channel attacks?
0 -
@johannesauer: Goldberg may want to elaborate, but in short 1Password's security needs to hold up on the client side too. Certainly there are some things we cannot defend against if your device is compromised. But that isn't a reason not to defend against the things we can. We worry about all of this so that 1Password users don't have to -- though security-minded users will anyway: it's not out of their way. :)
0
