@ChrisJohnRiley JtR was already exploiting this "flaw" for almost a year now. Nothing new here @SecPhil @1Password @hashcat @solardiz
Additionally, JtR supports the latest "Cloud Keychain" format as well and you can't beat those speeds
However, the speeds are awesome as usual. Good work atom!
After reading carefully I see that some of the optimizations are "new" (similar to what I did in O5LOGON format). Thanks for reporting them atom :-).
"Yes, even with the wrong IV, only the first block is incorrectly decrypted. Rest of the blocks are fine. So, we just need to decrypt the last two blocks and then use padding oracle attack."
Correction: only the last block needs to be decrypted since we can substitute second last block as IV. heh, thanks for the lesson on CBC mode atom
--- This isn't a mailing list, keep your posts condensed so it doesn't shit up the thread. ---
Additionally, JtR supports the latest "Cloud Keychain" format as well and you can't beat those speeds
However, the speeds are awesome as usual. Good work atom!
After reading carefully I see that some of the optimizations are "new" (similar to what I did in O5LOGON format). Thanks for reporting them atom :-).
(04-16-2013, 04:46 PM)atom Wrote: But if you take a close look now you see these both mechanisms do not match in combination. To find out if the masterkey is correct, all we need is to match the padding, so all we need to satisfy the CBC is the previous 16 byte of data of the 1040 byte block. This 16 byte data is provided in the keychain! In other words, there is no need to calculate the IV at all.
"Yes, even with the wrong IV, only the first block is incorrectly decrypted. Rest of the blocks are fine. So, we just need to decrypt the last two blocks and then use padding oracle attack."
Correction: only the last block needs to be decrypted since we can substitute second last block as IV. heh, thanks for the lesson on CBC mode atom
--- This isn't a mailing list, keep your posts condensed so it doesn't shit up the thread. ---