Twitter | Search | |
Michal Stanek @ 36c3 22 Jan 19
So I wanted to encrypt some files. Thought about using 7z+password. Stackexchange folks said "Didn't review it but it should be fine. You can browse the code yourself". So I did. After a few mins I noticed they use 8byte "random" IV. Yes, half of IV is zeroes. But it gets worse.
Reply Retweet Like
Gynvael Coldwind
Interesting find :) Could you comment on the impact of this? I mean, initial IV in such cases (i.e. archives+AES-CBC) is used to make sure it's not easy to determine whether two ciphertexts encrypt the same plaintext. But bad IV doesn't make AES-CBC decryptable, so.. low risk?
Reply Retweet Like More
Gynvael Coldwind 23 Jan 19
Replying to @3lbios
So if I'm not mistaking this flaw allows us to determine that two files are identical in two encrypted archives as long as: 1) The files were encrypted in the exact same microsecond (gettimeofday) or exact same CPU cycle (QueryPerformanceCounter) (1/2)
Reply Retweet Like
Gynvael Coldwind 23 Jan 19
Replying to @3lbios
2) The archives were encrypted using the same key/password. 3) The files are on the exact same position in the archive (otherwise we're in a different spot in the PRNG stream). Or am I missing sth? :)
Reply Retweet Like
0xFFFF_coffee Feb 11
Replying to @gynvael @3lbios
If you know the IV and the beginning of the plain text, you can use cbc malleability gadgets to change the plain text.
Reply Retweet Like
Gynvael Coldwind Feb 12
Replying to @0xFFFF_coffee @3lbios
In general? Sure. In this case however... You also need to take care of the integrity check - it's probably CRC32, but if you don't know the whole plaintext which you are modifying, nor the password, it sounds really guessy (even with how broken CRC32 is).
Reply Retweet Like
Bill 23 Jan 19
Replying to @gynvael @3lbios
Thanks for your analysis. It's not always easy to take a step back and ask the right questions.
Reply Retweet Like