Hot answers tagged

20

Brute forcing the key would hardly be an issue: 128-bit keys (assuming they have been properly generated) are in a space which is way too large to be successfully explored by brute force; and 256-bit keys (the kind you put in AES-256) are even more larger. Whether AES is "faster" than HMAC or not does not make such brute force more feasible: even if each key ...


17

Definitions / Introduction We define (this is solely for our example): $enc()$ and $dec()$ as the encryption and decryption function using CBC mode, with a constant key. any block cipher will do $\oplus$ is the XOR operation $n$ the amount of plain text blocks. the length of a block in bytes is $16$ (i.e. 128 bit) $m_1$ through $m_n$ the plain text blocks ...


9

Clearly, if you had been using AES-256-CBC for confidentiality and AES-256-CBC-MAC for authentication, it would not be secure to use the same key for both confidentiality and authentication. Hence, using the same key for confidentiality and authentication cannot generally be secure; you need additional premises to arrive at that conclusion. In your case it ...


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 ...


5

In the padding oracle attack you have an oracle that only tells you whether a particular chosen ciphertext decrypts to a correctly padded plaintext. That oracle is used to build a last word oracle, which used iteratively can reveal a whole message. The reason it works in CBC mode is that we can make predictable, arbitrary changes to the plaintext of the ...


5

Well, when TLS encrypts a stream of traffic, it breaks up the data into records. Each record contains up to 16k of data, and includes its own HMAC. Hence, there is no HMAC over the entire downloaded file; instead, there are a series of HMACs; every single byte of data is covered by one of those HMACs.


5

You have to differentiate between it being theoretically OK and practically. Without fully checking, I can say that such an approach may be possible to fully prove. However, practically, it is almost impossible to implement it. Specifically, you have to be able to make it impossible to differentiate between an error due to the symmetric decryption or the ...


4

Their attack does not recover the private key. Instead, it gives the attacker a way to decrypt an arbitrary ciphertext of the attacker's choosing. (This is not the same thing.) If the attacker has a ciphertext $c$, the attacker can query the hardware device tens of thousands of times and then based upon the responses, deduce what the decryption of $c$ is. ...


4

…are any other modes of operation vulnerable to padding oracle attacks? Nope, it’s purely restricted to CBC. A padding oracle attack, also known as “Vaudenay attack” because it was originally published by Serge Vaudenay in 2002 and introduced at EUROCRYPT 2002, is an attack against cipher-block chaining. The attack works against any block cipher in CBC ...


3

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 ...


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 ...


3

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): ...


3

We have a Padding Oracle if there is a different response from the server gives us an indication of the correctness of the pad (say if this needs proving). We can establish this by playing a game where we send badly padded cipher-text and random strings to the server, finally submitting some at random and seeing if we can get a non-negligible Advantage is ...


3

For a key recovery attack, you'd basically need to break AES itself. There are no known practical key recovery attacks on AES (and if there were, it would not be considered safe to use), so your pretty much only hope would be to find some kind of side-channel attack on the AES implementation, or on the overall crypto framework it is part of. Alternatively, ...


3

Quoting the answer here: Padding Oracle attacks are mainly a problem in cases, where e.g. an encrypted message is modified and send to a target. These attacks try to measure the difference when decrypting and validating the message. The steps are: decrypting the message checking the padding > error if wrong checking or processing the ...


3

Actually, we don't care about the amount of padding the original message had; we care whether the modified plaintext (that is, the result of the decryption of the modified ciphertext) has good padding or not. The padding will be valid if the last block had one of these patterns: XX XX XX XX XX XX XX 01 XX XX XX XX XX XX 02 02 XX XX XX XX XX 03 ...


2

All the details have been published in the paper titled "IEEE Symposium on Security and Privacy - Cryptography in the Web: The Case of Cryptographic Design Flaws in ASP.NET" http://netifera.com/research/poet/ieee-aspnetcrypto.pdf


2

If the last byte in the block is larger than the block size, that would generate a padding error in SSL 3.0. SSL 3.0 padding is up to $BlockSize-1$ bytes of unspecified data, and one byte with the length of the padding (not including the length byte itself). TLS 1.0 and above allow padding longer than the block size, and requires that each byte contains ...


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

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

You are basically using gzip to convey the length of the given message. As long as your implementation of AES-CBC is secure (e.g. by using a random IV) then the given scheme should be secure against padding oracle attacks. This is easy to prove as there is nothing that removes the padding from the plaintext. CBC padding in general does not add any security ...


2

The security of these schemes is all comparable, as far as I am aware. In all cases, you need to use authentication (e.g., Encrypt-then-MAC). Padding attacks are just one way that security can fail if you omit the authentication, but all of these schemes will have serious security problems if you omit the authentication. So, don't forget the ...


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

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 ...


2

There are many examples of real padding-oracle attacks in practice. SSL/TLS is arguably the most famous example. However, they appear everywhere. In a paper by Practical Padding Oracle Attacks by Rizzo and Duong they find a number of interesting examples. But, they are really all over the place.


1

You could look up the POODLE attack on SSL3 (pdf). It affected several implementations, but apparently e.g. OpenSSL 1.0.1i and earlier were affected. The idea is that an attacker can send modifier ciphertext for decryption (by a server which does know the key) and observe whether that results in correct padding. The pdf linked above outlines how it can be ...


1

In cryptography Oracle models a party in a given protocol that can answer to some precise questions. It is called Oracle because as the mythological Oracles, we don't know how they get the answer. This bit is very important in proven security as it allows to model a generic attacker and prove a protocol correctness against many possibles attackers. In real ...


1

I've written a script that breaks a cipher text based on a padding oracle for an assignment, but was wondering how I would continue on to create my own cipher text with any plain text I desired? You cannot. The padding oracle attack does not give you enough information to produce the ciphertext for any plaintext. You can do it for some plaintext, though. ...


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