I think one key point is a bit shaded in the long discussion -- if you have the key, you've decrypted the message. The rest is just details from a crypto perspective (but again, don't get me wrong, the practice is different and this is a great walk through).
On the IV I also think the description is a bit unclear. IV must be a nonce (i.e. number used only once), and it is public (i.e. known to the attacker in security proofs). It is usually random just because it's likely to expect that many random numbers will always be different.
I'm the average coder with no crypto skill that would have copy pasted the Crypto++ example.
I superficially understood what was being done in the article.
What I'm wondering is how hard it is to do that and is this skill-set common ? When I encrypt something I'm only sure that it will (hopefully) stop a script kiddie and be trivial for the NSA, but what about the other possible attackers ?
Any attacker above a script kiddie (where they can/want to make money off you) will have someone not as good as Dennis, but with the skill to do what's demonstrated here.
Not only has he the access to the code but he can even run it successfully over the encrypted data he "cracks" which means even without any "cracking," just by starting the program, he regularly produces the "uncracked" data.
Which means he doesn't even need to know how the "decryption" is performed, he just has to intercept the program results at the moment the data are in the decrypted form.
That means that it is effectively irrelevant which algorithm the developer used.
Just a small comment on this: "To my surprise, during decryption, AESENC is executed, while AESDEC is not".
Cipher modes like CTR, CFB use the underlying block cipher as a state update function for a keystream generator. The actual encipher, decipher is done separately. This means that the block cipher is used in the same way for both encipher and decipher.
I'm guessing this was not written by a native English speaker, so a bit hard to understand in some key ways. Not really being a crypto guy myself, that's just enough to make this hard to follow.
Just to confirm that I'm getting this... basically this is describing steps that might reverse engineer a C#/.net program that uses an embedded encryption key? Yes, a heavily obfuscated program, but the real weakness is that the key that encrypts the data exists within the code?
