Tag Info

Hot answers tagged

5

With pure asymmetric encryption there is no way to ensure integrity and authenticity, since anyone who knows your public key can encrypt any message for you. For that you would need either a symmetric key to use for a MAC (in which case you could use it/derivatives for symmetric encryption too) or a signature from the sender. And in the latter case the ...


3

First of all, a more usual padding scheme would add 5 times the same byte 0x05 (in your example) so the check not just removes 5 bytes, but also checks that the 4 bytes before it have the same value. But let's assume your scheme (which is underspecified: what to put in the bytes before? Zeroes, or random values?) for now. What if you cannot remove that ...


2

Yes, and it's devastatingly effective, too. See OAEP and other RSA/asymmetric-function padding standards. OAEP is what you should use these days so far as I am aware. PKCS#1 has other defined padding schemes also (eg PSS, PKCS1.5), only some of which are effective.


2

Why does this prevent the attack? Why doesn't the attacker just infer that the connection failed because of the bad padding? Why else could the connection fail? Well, the connection may fail because the host decrypted a valid pre-master secret, and it wasn't the pre-master secret that we expect. That is, when the attacker injects his encrypted message, ...


2

Bleichenbacher's attack relies on being able to determine whether the padding was correct or not. The patch tries to ensure that the following two (previously distinguishable) cases look identical to an attacker: the padding was correct, but the attacker has no knowledge of the transmitted pre-master secret — hence he can't use the resulting symmetric keys ...


2

Your suggestion is essentially what ISO 10126 does, since there's no way to verify the random bytes that make up the rest of the padding. You could do the same with e.g. PKCS #7 padding, as you suggest. However, this would leave a covert channel. If those other padding bytes are not verified, they can be chosen by the sender and even modified by an attacker ...


2

I unfortunately don't have enough reputation to comment, forgive the answer that is a link to another answer. Your question is explained well in this answer: http://crypto.stackexchange.com/a/12706/17884


2

You scheme, let's call it pad-MAC-encrypt, would indeed fix any padding oracle attacks against MAC-pad-encrypt. The reason it isn't used is probably that padding oracle attacks weren't known when CBC schemes were initially defined and now that they are known, there doesn't seem to be a convincing use case for CBC. Other modes have advantages over CBC anyway ...


1

I implemented this padding oracle attack some time ago in Python and remember this part being a bit confusing to wrap my head around, my code is as follows: newM = [] for (a, b) in M: # util.ceiling rounds arg1 / arg2 to the next highest integer rlow = util.ceiling((a*s - 3*B + 1), n) rhigh = (b*s - 2*B) / n for r in range(rlow, rhigh + 1): ...


1

The biggest reason is probably that padding is only required for CBC mode encryption. What you are doing here is to mix the cipher mode used for confidentiality with the MAC required for authentication. By doing this you are decoupling the padding from the decryption: CBC-decrypt; verify authentication tag; unpad. This may not be a problem to create as ...


1

With byte aligned data, bit padding allows the padding oracle attack. Every message has to end in a 0x80 byte followed by any number of zero bytes. You can iterate one byte at a time just like with many other byte paddings. If you allowed plaintexts that are not a full number of bytes long, the attack wouldn't be possible. (Every plaintext that didn't end ...



Only top voted, non community-wiki answers of a minimum length are eligible