

Encrypted database case #1 - kushti
http://yurichev.com/blog/encrypted_DB_case_1/

======
nly
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@....

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

------
samsaga2
He has a very nice book

[http://beginners.re/](http://beginners.re/)

------
jmnicolas
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
?

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

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

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

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

~~~
bvttf
like he says in the next paragraph, yes.

------
memming
typo: "CFB mode is also use"

~~~
dennis714
Thanks, fixed.

------
sbuttgereit
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?

