Score:0

Crypto

How to get the rest of 10 bytes (from total 32 bytes plaintext) of plaintext from a 48 byte ciphertext using AES-128 when knowing 22B of plaintext?

Sir Muffington

8/18/24, 4:01 PM

I have a challenge in which I need to decrypt 32(?) bytes of plaintext, which by encryption resulted in 48 (this for sure) bytes of data.

It's a black box challenge, but managed to figure out the above and below.

According to this https://security.stackexchange.com/questions/207633/decrypting-aes-128-cbc-leads-to-first-block-being-correct-the-rest-corrupt?rq=1 my IV is wrong, even though I extracted it from the application, which encrypts the file. I have the ability to encrypt any file I want.

The funny thing is when I use AES-128-CBC in CyberChef or in my custom C program, which uses OpenSSL I decrypt last 22 bytes of plaintext only. Other methods seem to fail to decrypt any senseful data.

Or is this a case of key wrapping/SIV/padding and if so how can I identify that and how can I decrypt the rest?

Since the IV is wrong I tried XORing it (like this https://cybergibbons.com/reverse-engineering-2/why-is-unauthenticated-encryption-insecure/ ) with the decrypted part, tried XORing the key, tried unwrapping the key and failed miserably, because of a IV mismatch...

1 + 5

aes

cbc

padding

Maarten Bodewes

8/19/24, 12:43 AM

Generally the IV are the first 16 bytes of ciphertext. So in that case the 22 bytes of plaintext is exactly what you need; the rest is probably padding with hex value 0x0A (probably already removed if you have 22 bytes / characters).

Sir Muffington

8/19/24, 12:00 PM

@MaartenBodewes thank you for your comment, but that seems to just give the same 22 bytes at the end and the start of the string is 16 bytes of junk. This might mean the initial plaintext was actually 38 bytes and not 32 bytes, which would make more sense considering the block size of 16 bytes

Maarten Bodewes

8/19/24, 7:33 PM

CBC encrypts any message size. There is no message size that is more or less probable. We don't get the 22 bytes of plaintext, is there any reason why this isn't the actual result you're looking for?

Sir Muffington

8/19/24, 7:37 PM

@MaartenBodewes because apparently the plaintext is clearly incomplete, I can tell. It's readable, in the right order, but the rest of the bytes are "scrambled" apparently..

Maarten Bodewes

8/19/24, 9:31 PM

[This final link](https://cybergibbons.com/reverse-engineering-2/why-is-unauthenticated-encryption-insecure/) points to a bad article. At least the title is wrong. Yes, if you implement authenticated encryption **yourself** and you forget to authenticate the IV, then authenticated encryption is not achieved. I'd not draw any information from that article for that reason alone.

Score:1

Crypto

Maarten Bodewes

8/19/24, 7:31 PM

The IV is often placed in front of the ciphertext. If you CBC-decrypt with the wrong IV then the first 16 bytes of random bytes is produced, followed by the actual plaintext.

With CBC the previous block of ciphertext is used "as a vector" for the next block. However, obviously that doesn't work for the first block as there is no previous ciphertext. However, that's just where the IV was placed, so the decryption works perfectly.

However, the first block is decrypted as well, and as that's not actual ciphertext, it will result in randomized data. Decoding that can result in any kind of (garbage) plaintext.

You've got a black box challenge. You may need to do things with the black box, e.g. mount a padding oracle attack to find out the IV. That is: assuming that the first block does not contain the IV of course.

+ 4

Sir Muffington

8/19/24, 7:43 PM

Woah okay, that's opposite to what I have read on bitflip attacks and similar :O (the in front part). But I trust you on this part, since you're a trustworthy moderator here on the site, and I'm still a beginner in cryptography. The plaintext should be bigger than 22 bytes though, that else could be at play here?..

Sir Muffington

8/19/24, 7:47 PM

Also I tested out your hypothesis - I created another 32 bytes of the character `A` (so 32 times the character `A`) WITHOUT a newline and could decrypt literally the second half of it (16/32 bytes). The first 16 bytes here seem to be junk/random bytes

Maarten Bodewes

8/19/24, 8:18 PM

This is just the generic description of how CBC works. Not sure how that can conflict with any attack. It could well be that this isn't the answer what you're looking for. If that's so then that's very likely because I'm missing context (e.g. with regards to incomplete plaintext). In that case it is unlikely that anybody can create an answer given the information provided.

Sir Muffington

8/19/24, 9:17 PM

Ohhh you meant in the process and not in the data itself. I feel stupid right now...

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: How to get the rest of 10 bytes (from total 32 bytes plaintext) of plaintext from a 48 byte ciphertext using AES-128 when knowing 22B of plaintext?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.