Hot answers tagged

19

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


16

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


8

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

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

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


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


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


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

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

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

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

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


1

I am afraid there are no efficient methods of knowing the padding methods deployed unless it is specifically provided by description from whomever authored the original codes. You have to try bruteforcing the padding scheme to estimate what padding schemes are used.


1

For a CBC mode cipher, which is what POODLE applies to, you don't encrypt or decrypt individual bytes, but rather blocks, formed by adding padding to the actual data bytes. For encryption in general every byte can be any value 0 to 255, and the SSL spec allows the padding_length byte to be almost any value, but most if not all implementations only use 0 to ...


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

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