Encrypted database case #1 | Hacker News Reader

Encrypted database case #1

yurichev.com

143 pointskushti12 comments

For those following along at home

    $ echo "yjmxhXUbhB/5MV45chPsXZWAJwIh1S0aD9lFn3XuJMSxJ3/E+UE3hsnH" \
    | openssl enc -d -a -aes-128-cfb -iv 01000000FFFFFFFF79C1690B67C1047D \
    -K CDC57EAD285F6DE1CE8FCC29B121888E | xxd

    0000000: 0d00 fffe 4600 5200 4100 4e00 4b00 4900  ....F.R.A.N.K.I.
    0000010: 4500 2000 4a00 4f00 4800 4e00 5300 0000  E. .J.O.H.N.S...
    0000020: 0000 0020 6640 d407 0601                 ... f@....

Really cool writeup, thanks!

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.

He has a very nice book

http://beginners.re/

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.

It's not that different from lots of DRM breaks.

Here "cracking" should be understood as deciphering while having access to code that deciphers the database.

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.

like he says in the next paragraph, yes.

typo: "CFB mode is also use"

Thanks, fixed.

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?

Reply on news.ycombinator.com