0
$\begingroup$

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

Improve this question
$\endgroup$
5
  • $\begingroup$ 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). $\endgroup$
    – Maarten Bodewes ♦
    Aug 19 at 0:43
  • $\begingroup$ @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 $\endgroup$
    – Sir Muffington
    Aug 19 at 12:00
  • $\begingroup$ 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? $\endgroup$
    – Maarten Bodewes ♦
    Aug 19 at 19:33
  • $\begingroup$ @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.. $\endgroup$
    – Sir Muffington
    Aug 19 at 19:37
  • $\begingroup$ This final link 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. $\endgroup$
    – Maarten Bodewes ♦
    Aug 19 at 21:31

1 Answer 1

Reset to default
1
$\begingroup$

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.

Improve this answer
$\endgroup$
4
  • $\begingroup$ 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?.. $\endgroup$
    – Sir Muffington
    Aug 19 at 19:43
  • $\begingroup$ 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 $\endgroup$
    – Sir Muffington
    Aug 19 at 19:47
  • $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes ♦
    Aug 19 at 20:18
  • $\begingroup$ Ohhh you meant in the process and not in the data itself. I feel stupid right now... $\endgroup$
    – Sir Muffington
    Aug 19 at 21:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.