Padding Oracle Attack

What is padding oracle attack? Some people interpret the padding oracle attack as one of the types of SQL injection or exploit on Oracle database. Padding oracle attack actually has nothing to do at all with the oracle database, this is the type of attack the interrogation ' the oracle ' then with simple math (XOR operation) using the answer ' the oracle ' for mendekrip ciphertext.

 

Block Cipher vs Stream Cipher

There are usually two way encryption and decryption algorithms process the data:

 

• Block Cipher.
  Encryption and decryption of a block of plaintext and ciphertext are specific (e.g. the block size is 64 bits or 128 bits). In the block-cipher encryption, if the data consists of many blocks, all block dienkrip/dekrip with the same key. Examples of block-cipher encryption algorithms are DES and AES
• Stream-cipher.
  The Data is regarded as a stream of bits/bytes, enkrip and dekrip process undertaken against a bit or a byte every time as in the production of goods flow through the assembly line/conveyor belt in a factory. When in block-cipher all blocks using the same keywords, in stream-cipher every bit/byte dienkrip/dekrip with a different key using the key stream (keystream) pseudo-random ones in kind of a certain-sized key (40-bit 128 bit). Examples of stream-cipher encryption algorithm is RC4.

Mode Operasi Block-Cipher

Block cipher encryption algorithm like AES/DES themselves actually only designed to perform encryption/decryption of a block or blocks of plaintext ciphretext only. For example, AES, designed to transform plaintext size is 128 bit (with a key size of 128/192/256 bit) into ciphertext 128 bit-sized as well.

 

When there is only one plaintext/ciphertext block, then encryption and decryption can be done directly on the block. However, if large and ciphertext/plaintextnya after the cut pieces are assembled in more than one block, surely there must be a way/procedure for processing the blocks, this procedure is called operation mode. In the mode of operation described how the encryption/decryption is done against a plaintext blocks/the ciphertext, how the relationship between a block with another block, blocks do I need to dienkrip/dekrip first and so on.

Some examples of the operating mode is the ECB and CBC. Keep in mind that the operating mode is not an encryption algorithm, encryption algorithm like AES/DES can be operated in many different operating modes such as AES-CBC (AES in CBC mode of operation), AES-EBC (AES mode of operation in the EBC) and so on. So the operating mode is more like a Protocol/procedures to operate a particular encryption algorithm.

 

Electronic Code Book (ECB) Mode

 

The simplest approach is to update with enkrip/dekrip any such blocks individually, independently. One block and other blocks have nothing to do and processed individually. Mode of operation the way it is referred to as a mode of ECB (electronic code book). The image below shows the process of encryption and decryption in ECB mode.

 

In the image above to see that each block will be dienkrip/dekrip apart, no relation to each other. What happens when the Plaintext contents of 1 and 2 the same Plaintext? Block cipher algorithm for in all blocks using the same keywords, of course if the plaintext block 1 and block 2 identical plaintext will produce ciphertext block 1 and block 2 ciphertext that is also identical. This is a weakness of ECB mode when any plaintext blocks are identical, then ciphertextnya will be identical so it will also exhibit the pattern easier to see in ciphertext.

 

 

 

 

 

The EBC mode this will disadvantage is clearly visible when updating the enkrip documents/data that has many of the same data as the image which usually have lots of rows of pixels whose color is the same. In the picture above (wikipedia image), because a lot of the area that the colour is the same as the background color of white, black and yellow, making the image file when it is cut into pieces would have had a lot of blocks that are identical. ECB Mode can not even guarantee confidentiality because the image is still visible after pinguinnya is encrypted.

This weakness is weakness of the mode of operation, not a enkripsinya algorithm. So it's as strong as any enkripsinya algorithm, when operated within the ECB mode, the results will also contain the same flaws (plaintext blocks identical ciphertext blocks generating identical).

 

Cipher Block Chaining (CBC) Mode

 

When in a mode of ECB (electronic code book) each block in-enkrip/dekrip singly independently, in CBC mode (cipher block chaining), a block and other blocks are intertwined (chained). Here the meaning is related encryption and decryption of a ciphertext data block always involves (the encryption) the previous block.

To plaintext blocks are identical does not produce ciphertext blocks are identical, the CBC mode (cipher block chaining) Associate (chaining) one block with the previous ciphertext block and uses random initialization vector (IV) as ciphertext blocks to-0. The workings of the CBC mode is like in the picture below.

 

 

 

Each block of plaintext-ciphertext with XOR's results the previous block encryption of the plaintext and then XOR operation results of these dienkrip to generate the ciphertext block. Vice versa when decrypting. Decryption is done against a block of ciphertext plaintext blocks do not directly generate, the decryption must be first with ciphertext blocks are XOR earlier to produce the plaintext block. So encryption and decryption always involve block ciphertext before.

 

 

In the form of mathematical notation, can be seen below:

Variables that are used in the formula above:

⊕ = Notation for eXclusive OR

P = Plaintext

C = Ciphertext

IV = Initialization Vector (might be construed as C0)

Ek = Encryption with the key k

Dk = Decrypt with the key k

P1 = Plaintext blocks to-1

P2 = Plaintext blocks to-2

Pn = Plaintext block n

C1 = Ciphertext block 1

C2 = Ciphertext block 2

Cn = Ciphertext block n

 

 

IV (Initialization Vector)

If in any encryption/decryption should involve the ciphertext block before, what about the encryption/decryption block first? Because of its position is the first block, then of course no ciphertext blocks to-0 (C0).

Because there is no C0, then needed a data that serves as the C0, this data is called with the IV. With the IV, encryption/decryption block of ciphertext block needs first before the first (actually no), can use the IV as (ostensibly) ciphertext blocks to-0.

IV selection should not be carelessly, IV wherever possible random and unique, don't use a predictable and repetitive IV (IV used for yag same same keywords). IV actually need not be kept secret, because IV could also be considered part of the ciphertext as well (C0), but if it will indeed complicate IV concealed attacker get the first block.

Padding

In a block-cipher the plaintext and ciphertext must be cut into pieces and arranged in blocks of data of the same size. For example, the DES block size and Blowfist use 64 bit, AES uses a 128 bit-sized blocks. Because the data must be entered in blocks of the same size, then the required padding bytes as data to fulfill the mountings to fit the size of the block.

The rules regarding the padding described in the standard PKCS # 7 and PKCS # 11 (Public Key Cryptographic Standard). Padding is done by filling out the N-valued bytes when needed as much padding N bytes. For example, if it takes 3 bytes of padding, then paddingnya contains ' 03 03 03 °, if required, then 5 padding bytes contains paddingnya ' 05 05 05 05 05 °.

Some examples of the right padding shown in the image below.

 

There may be viewed on the oddity that the way the padding on the top. If the data already contains 8 bytes ' ABCDEFGH ' why still need padding? Isn't padding only to data that is not even 8 bytes?

In the PKCS standards are already set up that must be added the padding all data, even though such data is even the size of a block is necessary. So if the data block is 8 bytes, then regardless of the size of the data, the padding is added, it should be at least 1 bytes, maximum of 8 bytes.

Byte padding ' dummy ' this needs to be added to avoid confusion. Imagine if the paddingnya rule does not add padding on blocks that have the same size blocks as needed. When the sequence of bytes in the block was ' 41 42 43 44 45 46 47 01 ° as shown above, the system will determine if the data block is confused is ' ABCDEFG ' and 01 byte padding, or its data is indeed ' ABCDEFG ' + 01 byte (byte 1 is part of the data, not the padding bytes).

Some other examples of valid padding as in the picture below. When in a block of 8 bytes is byte 01 all, the last byte of padding is regarded as 1 byte, so that counts as data is 7 bytes only. Similarly, when in one block, 5 final byte value 02, then the last two bytes are considered to be padding bytes, so the data is considered to be 6 bytes.

 

Invalid Padding

 

Padding oracle attack works by detecting the response from the server that tells the client whether padding is valid or not. Keep in mind that checking the padding is done after the decryption was completed.

Detect whether the padding bytes are valid or not, begins by looking at the last byte the last block and then saw new byte-byte before the content of the final byte is dependent. For example, some of the conditions that determine the padding on the block size is 8 bytes (64 bits) is valid or not valid, among others:

• When the last byte of value outside the range 01 – 08, then the padding definitely not valid

• When the last byte is 01, then the padding value must be valid

• When the last byte is 02, then padding value is valid when the previous byte is 02

• When the last byte is valuable 03, then valid if the padding 2 bytes before also 03

• When the last byte is worth 10, then 3 bytes of padding are valid when previous 04

• When the last byte of value 05, then valid if the 4 bytes of padding was previously too 05

• When the last byte, then the padding value 06 valid if previous byte is also 5 06

• When the last byte of value, then the padding valid 07 when 6 bytes previously also 07

• When the last byte, then the padding value 08 valid if previous byte is also 7 08

Some examples of invalid padding shown in the image below.

 

The Encryption Process

Let's look at the details of a data encryption process. In this example we will look at the process of encrypting a plaintext ' ABCDEFGHIJKLM ' with ' secret key ' use of DES CBC mode. In this example the IV used is a sequence of bytes (01 02 03 04 05 06 07 08).

 

Because of the length of the plaintext is 13 bytes, then the padding needed is 3 bytes so that even being 2 blocks sized 8 bytes. After added padding, the first block contains ' ABCDEFGH ', the second block containing ' + ' + IJKLM 03 03 + 03.

 

Keep in mind! At the time of encryption, padding is added to the plaintext. At the time of decryption, the plaintext decryption will be checked, whether valid or not bytenya padding.

After 2 blocks, formed the encryption process can be started from the first block plaintext (P1) with IV, diXOR then result in-enkrip and became the first block of ciphertext (C1). The second block of Plaintext (P2) with the first block of ciphertext diXOR (C1), then the result becomes the second block of ciphertext dienkrip (C2). Note the process bytes per byte in the image below.

 

 

 

The Decryption Process

After the encryption process is done, now we will also look at the process of decryption. C1 didekrip be rows of bytes ' 40 40 40 40 40 40 40 40 ° then diXOR with IV to produce the plaintext block 1 (P1). Next block C2 didekrip into rows of bytes ' 64 32 1B B8 AA 08 0A 86 ° then diXOR with plaintext to produce C1 block 2 (P2).

 

 

Because the key and ciphertext that dekrip is true, then the process of decryption in the figure above yields the correct plaintext. But when the ciphertext is not didekrip correct, or ciphertext key is wrong, then the process of decryption will be done according to the procedure, but the results are not the original plaintext data, however, irregular byte (garbled text).

 

Keep in mind. The decryption process will still be done despite the ciphertext or the key is wrong. Ciphertext and the correct key will didekrip be true plaintext, ciphertext, however, or the wrong keys will be didekrip into plaintext (irregular byte sequences, garbled text)

Padding Validation

Decryption processes do not stop after the decryption is complete. After the ciphertext in-dekrip, next will be made in the form of separation where the byte data (plaintext) and where the form of byte padding bytes.

The separation of data and padding can only be done when the decryption results contain padding bytes are valid. Remember that the results would not necessarily yield the plaintext decryption is right (or wrong key when ciphertext, the result is also wrong), so there is a possibility of decryption results are data bytes which naturally irregular byte paddingnya is not valid.

In the example image above, because the key and the ciphertext is true, then the result is also generating the plaintext decryption right with a valid padding bytes (the byte sequence 03 03 03). In the above example, because the paddingnya is ' byte 03 03 03 °, then it can be separated between the plaintext data and byte padding by way of disposing of the last 3 bytes, the remaining (' ABCDEFGHIJKLM ') is the plaintext data. If the decryption process is simplified by the image above be (green = block 1, blue = 2 blocks):

 

But what if ciphertextnya wrong? Let's look at example ciphertext is wrong, and we will see what the results are when the ciphertext of didekrip. What if the first block of ciphertext is converted his last byte of 0 × 85 to 0 × 83.

 

Although ciphertextnya has been changed, the decryption process continue to run as usual because the encryption/decryption algorithm works turning the bit size of a block, regardless of the content of the input, other bits are set to become a block as well.

Note that the last byte plaintext is worth 50, but the last 5 bytes of plaintext doesn't contain 05 Standard PKCS padding, meaning that the plaintext contains padding error. So the decryption algorithm will still be mendekrip all input coming in, regardless of the content of the input, although later results invalid decryption paddingnya.

Now we try again with other ciphertext, this time the last ciphertext block of the first byte is converted to bytes 0 × 86. Let's see what happens.

 

After didekrip turned out to be the final decryption results byte value 00 means not valid byte padding (padding bytes of value valid 01-08 for a block size of 64 bits).

Okay, let's try once again for more ciphertexts. This time the last ciphertext block of the first byte is converted to become 0 × 87, let's see what happens.

 

This time it turned out to be the final decryption results worth the bytes 0 × 01. Because the last byte is 01, the value can be ascertained without valid paddingnya need to see other previous bytes bytes.

Malleability

Let us note once again the difference between the original and the ciphertext is modified below.

 

Before the change, the padding bytes are plaintextnya 03-03-03 so that data is considered ' ABCDEFGHIJKLM '. By changing the ciphertextnya one byte of 0 × 85 to 0 × 87, the last byte is now no longer plaintextnya 0 × 03, changed to 0 × 01 so that data is considered ' ABCDEFGHIJKLM ' + 03 + 03 (now 03 is considered data, byte is not part of the padding).

Note that turned out to change one byte of ciphertext, could produce the plaintext is equally valid, however its contents are different. This trait is called with a malleability.

To understand the danger of this malleability, imagine the property there is a man-in-the-middle attacks an intercept ciphertext, then change one byte of the ciphertext before continuing on to the goal. Upon arriving at the destination, the ciphertext is modified earlier when didekrip generates a different message referred to in the original message. It is certainly harmful when the contents of the message changed from "send money 1 million into the account 123 ° turns into" send money 1 million to 124 °.

The Oracle

In the padding oracle attack, is the Oracle here has nothing to do at all with SQL, and Oracle database.

Oracle is oracle's validation, where we can ask and be answered by oracle to answer Yes or no, true or false, or other conditions. Sometimes oracle doesn't reply verbally (blind-answer), it might just be the difference between (the timing-attack), when the answer is correct, then it's time for longer than if the answer was wrong.

Whatever and however is how to respond when the client can tell which means valid response, and padding where the response which means invalid padding, it means the server has become ' the oracle '.

In a web application, usually responded with oracle html text "Error", "Stacktrace", "Invalid Padding Exception" or similar error message. Another way to answer is to distinguish between the status codes of HTTP, when the answer is wrong, its status ' 500 Internal Server Error ', when really his status ' 200 OK '.

The workings of the padding oracle attack is like in the picture below.

 

Attacker performs brute force by sending many to get the ciphertext which variant the Variant that produces valid ciphertexts padding. The Ciphertext is sent to ' the oracle ' in the form of two blocks, the first block has always been fickle when doing a brute force ciphertext blocks to find a Variant that generates the response is valid, while padding the second ciphertext block is didekrip and does not want to change when doing a brute force.

Note that didekrip want to block is placed as the second block of ciphertext sent to ' the oracle '. When the ciphertext is no more than one ciphertext block, we can freely choose to mendekrip the block where it used to be, a clear way is by putting a block of ciphertext to didekrip as a second block of ciphertext block 2 sent to ' the oracle '.

Exactly how the process then, why just by observing the response is valid or invalid padding, how can mendekrip ciphertext without knowing the key? For more details I will explain with the following example.

Example Scenario

A web application stores the encrypted data on the client in the ' URL parameter ' crypted. A cybercafe customers found the following URL in the address bar history list computers in Internet Cafe:

http://localhost:8888/kripto/thematrixoracle.php?crypted=2D7850F447A90B87123B36A038A8682F

When the URL is opened, the ciphertext is sent to the server in the parameter, then the server will be crypted gave a response:

' 500 Internal Server Error ' when paddingnya is invalid.

' 200 OK ' if paddingnya is valid.

Block cipher algorithm used is DES 64 bit sized in CBC mode (cipher block algorithm-any used is not important, padding oracle attack attack the CBC mode block cipher algorithm-any used). In this scenario the source code used in the oracle server is:

Without knowing the key, just use the answers from the oracle, how does the Internet Cafe customers last for mendekrip the content parameter of the crypted?

Get the last byte of P2

Now it's time attack padding oracle. We'll try mendekrip C2 one byte per byte, starting from the last byte and then advanced to the first byte.

The first thing to do is to break ciphertext which is found from the browsing history above, into the blocks. Because of the length of the parameter on the URL crypted is a 32 byte string, meaning that the length of hexa is 16 bytes, then it could be presumed that this is a block-cipher with a block of length is 8 bytes.

Next was break up the ciphertext into the block. Once broken down into 2 blocks, obtained C1 = ' 2D7850F447A90B87 and C2 = '/123B36A038A8682F '. This is the block C1 and C2 of the original found in the URL of the browsing history.

We begin with the last first block C2 mendekrip (' 123B36A038A8682F '). As already mentioned earlier, we would have to send two ciphertext blocks into ' the oracle ':

1. The first block is a block of ciphertext custom made attacker. This block of bytes originally could contain anything (random or null byte), the important thing is the last byte that affects padding should be sought by means of brute force to create padding to be valid. 
2. The target block will be didekrip (' 123B36A038A8682F '). This block is fixed in each request because this will block didekrip

Two examples of the block cipher that is sent to the server is like below.

 

In the picture above we use the row of 7 null bytes (byte 00) and one last byte for brute force ranging from 00 to FF, for ciphertext blocks first. Whereas the second block remains unchanged during the brute force because it is the target that will block didekrip.

The two ciphertext blocks in the picture above towed then sent to the server. Server as ' the oracle ' will mendekrip the ciphertext block 2 and give a response would produce the plaintext with a valid or invalid padding.

We will start from the last mendekrip C2 byte, then get a byte by one byte until the first byte C2. Because you're looking for is the last byte of P2 (decryption C2), then we have to find the last ciphertext block of the first byte that make P2 be worth 01 (invalid padding). The situation is reflected as in the picture below.

In the picture above, there is one equation but with two unknown variables, A XOR B = 01, should this equation cannot be solved. But fortunately we've got ' the oracle ', he's going to help us solve the equation. How do the trick?

We can interrogate ' the oracle ' by trying all possible B ranging from 00 to FF because it is between 00 and FF there must be BS that makes ' A XOR B = 10 ° to right. We could ask ' the oracle ' to the following questions:

Will A XOR 00 = 1?

Will A XOR 01 = 01?

Will A XOR 02 = 01?

Will A XOR 03 = 01?

Will A XOR 04 = 1?

Will A XOR 05 = 01? dst

When ' the oracle ' replied with ' invalid padding ', it means to answer the above questions is ' no ' and we have to ask the question to the next byte to FF. Instead when the oracle answered with ' invalid padding ', meaning that it answers the above questions is ' yes ' and we've managed to find the B.

Brute Force Was The Last Byte

To make it more clear let us look deeper process of brute force to get the last byte of C1 makes the P2 became the last byte is 01 so that paddingnya is valid.

In the picture above look client sends the ciphertext 3 variants. In the first variant, the last ciphertext block of the first byte is 00, after mendekrip this ciphertext, ' the oracle ' was answered with ' invalid padding '. When sending a ciphertext, in fact we are currently interrogating ' the oracle ' with the question ' what is A XOR 00 = 1? ', and it turns out the answer is ' no ' so we should try with another question.

The Client does not know the decryption ciphertext which she tell be what. The Client can only be guessing based on the response from ' the oracle '. Because responsnya is invalid padding, suspect and sure that client bytes last definitely not 01. Even though the client had no idea what, but decryption results client know that the last byte is 01, certainly not information-leak as small as that alone is enough to mendekrip ciphertext without knowing the key.

In the second variant, the last ciphertext block of the first byte is raised to 18, but the answer ' the oracle ' is still the same, i.e. ' invalid padding ', meaning decryption results certainly not end with 1 byte. This time we asked the question ' what is A XOR 1 = 1? ', it turns out the answer is still ' no '.

In the third variant, the last ciphertext block of the first byte is raised again becomes 02, but still also answer ' the oracle ' is ' invalid ' padding. In this request we ask the question ' what is A XOR 02 = 01? ', unfortunately the answer is still ' no '.

The Client should continue to try to raise the last ciphertext block of the first bytes of 00 to FF because it is between 00 and FF there is certainly one that generates a status byte padding. The image below of the brute force process above until finally the client discovers that the last byte is 0 × 87 will make the status of padding to be valid.

Hooray, after trying the byte 00, finally on request to 88, it brings that last byte is generating valid response 98 padding. This time we got an answer ' yes ' from ' the oracle ' to the question ' what is A XOR 87 = 01? '.

Once the can is valid padding, so what? In fact there is something cetar formations here, let's look at more details more bytes per byte of what happened (Bytes that contain '?? ' meaning is not known of its contents by the client).

The picture above is important to understanding the padding oracle attack. We look back on what happened.

1. Client sends 2 blocks with the last ciphertext block of the first byte value 0 × 83 
2. Mendekrip ciphertext from the client Server 
3. After the last byte of value turned out to be didekrip 01 (valid padding) 
4. The Client detects the response from the server that the padding is valid 
5. Because of the padding is valid, the client suspected (and believe) that the last byte of ciphertext decrypted results that he send is 01

Okey, so far only the client knows the bytes 0 × 87 and byte 0 × 01, what could be obtained from it? The answers are in the picture above, we call it green byte as A.

From the previous equation ' the oracle ' answered ' yes ' to the question: is A XOR 0 × 81 = 0 × 01. Previously this equation had two unknown variables, now live one, which means that this equation can be solved. Then what is A?

The answer is easy, A is 0 × 87 ⊕ 0 × 01 = 0 × 86. Hooray! By detecting invalid padding/no response from the server, the client can now find out A is 0 × 86, but wait, A what? The answer is also in the picture above.

In the picture above is clear, A green is the last byte of the Decrypt (C2). But don't keburu happy first, remember that Decrypt (C2) not P2, there is still one more step to be P2, still needs to be used with a C1 XOR to make P2.

Because the last byte C1 is 0 × 85 so that we can get the last byte of P2 is 0 × 86 XOR 0 × 85 = 0 × 03

Get byte 7 P2

After successfully getting the last byte of P2 is the next mendekrip 1 bytes before the last byte.

The trick is similar to the previous, i.e. by making that padding decryption ciphertext sent client, to be valid. But a bit different than before, this time the desired conditions of valid padding is syllabic byte 02-02. The situation is shown in the image below.

Why is the last ciphertext block of the first byte is we set contains 0 × 84? In the picture above, it is clear that 0 × 86 XOR something = 0 × 02, then something that is 0 × 84, simple math).

Now live the last byte before still do not know how to generate required 0 × 02 because there are two question marks there, so if the written equation: A XOR B = 21, what is A and B?

An equation with two variables is not known should not be completed. How to find A and B equals before, we'll interrogate ' the oracle ' to help solve the equation in the form of brute force as follows:

1. Will A XOR 00 = 2? 
2. Will A XOR 01 = 02? 
3. Will A XOR 02 = 2? 
4. Will A XOR 03 = 02? 
5. Will A XOR 04 = 02? 
6. Will A XOR 05 = 2? dst

Once again, the brute force that we do with many variants of the ciphertext essentially interrogate ' the oracle ' to help solve the equation above. If ' the oracle ' respond with a status of ' invalid padding ' that means the answer to the above questions is ' no ', meaning that it should try with the next question. When ' the oracle ' respond with a status of ' invalid padding ' that means the answer to the above question is ' yes '.

The image below is a picture of the brute force process is done.

After dibrute force ranging from 00, status valid obtained when 2 padding bytes of value last 0A -84. Back again into the above equation, the answer to this same status valid padding means that with the answer ' yes ' to the question ' what is A XOR = 0A 02? ' so that A can be calculated easily, that is XOR = 0A 02 08. The situation is now becoming like the image below.

The contents of the byte of P2 now can already count i.e. 08 XOR 0B (0B is 7 bytes of the original C1) = 03.

Get the 6th byte of P2

This time the client should send the two ciphertext blocks such that when didekrip on the server, the result is a P2 with the last 3 bytes containing 03-03-03. The situation now is like the picture below.

In the figure above, the two last ciphertext block of the first byte is stuffed with 0B -85 to ascertain when the last byte diXOR produces 2 P2 03-03. Now the 6th byte should be sought by means of brute force, interrogate ' the oracle ' to solve the equation A XOR B = 03. Brute force process to get a valid padding shown in the image below.

After gaining the status of valid padding, meaning we've got the answer ' yes ' to the question ' what is A XOR A9 = 03 ° so that it can be counted A is 0xAA. The 6th Byte of P2 is true 0xAA 0xA9 XOR (A9 was the 6th byte of the original C1) = 0 × 03. The situation now is like the picture below.

So far we've managed to get the last 3 bytes of the decrypted result, i.e., the Divisione 03-03-03.

Get the 5th byte of P2

Get the 5th byte is also done by sending two block cipher such that when didekrip on the server generates a valid padding with final byte 04-04-04-04. The situation is like the image below.

The first three bytes of the last ciphertext block contains AE-0 c to ensure that the Eagle when it generates the last 3 bytes diXOR P2 04-04-04, interrogate ' the oracle ' to solve the equation A XOR B = 10. Brute force process to get a valid padding shown in the image below.

After gaining the status of valid padding, meaning we've got the answer ' yes ' to the question ' what is A XOR 0E = 10 ° so that we can calculate A i.e. 0A. After getting the 0A, we can calculate the 5th byte of P2 are original, that is XOR = 4 d 0A 54. So far we've got are reflected below.

Get the 4th byte of P2

Get the 4th byte is done by sending the two ciphertext blocks such that when didekrip on the server generates a valid padding with the last byte 05-05-05-05-05. The image below illustrates the situation.

Brute force manner similar to before, note that when the 4th byte of the first ciphertext block contains the response from the server 0xBD, is padding.

By obtaining valid padding status means that we got an answer ' yes ' from ' the oracle ' to the question ' what is A XOR BD = 10 ° so that A can be calculated i.e BD 05 = XOR B8 and the 4th byte of P2 be B8 XOR F4 = 4 c. The picture below shows the current situation.

3 more!

Stay 3 bytes again yet. Let's continue. Get the 3rd byte of P2 is done by sending a ciphertext block makes 2 6 bytes of the last P2 became the 06-06-06-06-06-06.

We must membrute force of the 3rd byte C1 ('?? ' blue cyan) to get a response from ' the oracle ' that the padding is valid. When getting invalid padding, the client can be sure that the 3rd byte of P2 is worth 20 so that the last 6 bytes being 06-06-06-06-06-06.

By obtaining valid padding status means that we got an answer ' yes ' from ' the oracle ' to the question ' what is A XOR 1 d = 6 ° such that A can be calculated that 1 d XOR 06 = 1B and 3rd byte of P2 be 1B XOR 50 = 4B. The picture below shows the current situation.

2 again!

Stay 2 more, come a little more nih! Now the client has to send the two ciphertext blocks that make P2 into 07-07-07-07-07-07-07.

The following is the process to find the brute force that produces valid byte padding.

By obtaining valid padding status means that we got an answer ' yes ' from ' the oracle ' to the question ' what is A XOR 35 = 7 ° such that A can be calculated that 35 XOR 07 = 32 and the 3rd byte of P2 XOR to 32 78 = 4A. The picture below shows the current situation.

Last!

Now it's time we look for the first byte of P2.

The following image is the brute force process to obtain valid padding.

By obtaining a valid lead byte of padding is 6 c, meaning we got an answer ' yes ' to the question ' what is A XOR 6 c = 08 ° such that A can be calculated: 6 c XOR 8 = 64. After that we can calculate the first byte, that is XOR P2 64 2D (the first byte of the original C1) = 0 × 49.

C2 Decrypted!

So we now have been successfully C2 mendekrip (' 123B36A038A8682F ') became ' ' + IJKLM 03 + 04 + 03 starts from the last byte to byte the first without knowing the key and the algorithm is what is used.

Decryption is done amazingly again not at all using the techniques of complex high level computing (permutations, the S-BOX is not needed at all), just XOR XOR datapun here, there manages to didekrip. So how come? This could happen because the decrypt is a server, serverlah will perform complex computations to ciphertext, mendekrip outside attacker stayed to observe the response of the server as ' the oracle '.

So it's as good as any enkripsinya algorithm, when CBC mode using and give a response on the client are valid or invalid padding, it will be vulnerable, although enkripsinya algorithm itself is not actually vulnerable. Padding oracle attack attack this instead of attacking the encryption algorithms like DES/AES, this attack strikes the CBC operating mode.

Decrypt C1

After the C2 successfully didekrip, how do I mendekrip C1 (' 2D7850F447A90B87 °)?

Same as mendekrip C2, C1 is way to mendekrip by forming two ciphertext block follows:

• Custom made blocks attacker

• Block C1 (' 2D7850F447A90B87 ') as the target to be didekrip

Then two such blocks are merged (concat) and sent to the server. Furthermore how is similar to the previous one. Here is a picture of the situation while searching for the last byte of the decryption of C1. Same as before, the first block contains null bytes except the last byte will be dibrute force, the second block contains a 2D-78-50-F4-47-A9-0B -87 to be didekrip.

Here we start over again, departing from the last byte to byte first. We must interrogate ' the oracle ' to help solve equations ' A XOR B = 6 ° What is the A and B? The following is the process to find the brute force that makes the last valid byte padding.

After getting a status of invalid padding means that we've got the answer ' yes ' from ' the oracle ' to the question ' what is A XOR 41 = 01 ° so that we can calculate A is 0 × 40.

Remember to mendekrip a block, we need the previous ciphertext block. Previously when we mendekrip our C2 to XOR-kan Decrypt (C2) results with C1, now because we're mendekrip C1, then we need a previous block ciphertext as well, i.e. C0 or Initialization Vector (IV). In this example the IV used is the byte array 01-02-03-04-05-06-07-08.

We already get the Byte is 0 × 40 should we XOR it with the last byte IV 0 × 08 to get the plaintext byte last, that is XOR 0 0 × 40 × 8 = 0 × 48.

We have been getting the last byte of the decryption of C1, the process can continue to get byte-byte before the last byte in a way that is similar to the previous one.

Related Posts :