AES question

[SPP]

Hi to all (and sorry for my english),

I've seen some encryption example with AES256 (I really liked NetMaestro code).
My question: it's safe to store the key and initialization vector as a data block?
Is posible to obtain from the compiled exe?

Thanks.

[idle]

yes the key would be visible but not necessarily obvious.

[SPP]

Idle,
Thanks for your reply but... can you explain a little more, please?

[netmaestro]

It's the "not necessarily obvious" part that you would want to focus on. You could, for example, create a datasection with a lot of things in it. Lots of text for messages, all kinds of numbers for various purposes, some needed and some added for ballast. The key here is lots and lots. Then, you would pick a pattern of where various parts of the key and iv are located in the data and your code would build the key/iv combo when it's needed. Nobody perusing your exe in a hex viewer would ever find the key, although someone determined enough and skilled enough could dump the asm instructions and learn how the key is built. An average programmer would probably be beat but a cracker of some skill would get it pretty soon.

[codewalker]

Nobody perusing your exe in a hex viewer would ever find the key, although someone determined enough and skilled enough could dump the asm instructions and learn how the key is built. An average programmer would probably be beat but a cracker of some skill would get it pretty soon.

Then this makes me wonder how the guys behind truecrypt are doing it. Truecrypt also uses AES
and in cases where a key of 15 or more random characters was used, even the FBI could not get
into a laptop of a certain suspect. This was not so long ago in the news.
cw

[Shield]

[...] although someone determined enough and skilled enough could dump the asm instructions and learn how the key is built. An average programmer would probably be beat but a cracker of some skill would get it pretty soon.

You don't have to evaluate all the ASM stuff and learn how the key is built.
When the application collects all parts of the key, the key has to be loaded into a memory section (string, array, ...) and will be visible.
The only thing a cracker has to do is check where the AES function call is and then grab the key.

(It probably sounds easier then it actually is, but the point is, saving a key in applications is never a good idea).

[SPP]

Thanks a lot for your replies,

My conclusion is: Never save the key in the code but for certain applications (i think) is necessary do it.
Then... how?

Best regards.

[Shield]

Depends on what you want to do.
Say you want to upload files on a server, it's better to do this via HTTP and user user-logins
instead of giving the user your FTP login, for example.

[SPP]

Hi Shield,

Your suggestion is store the key out of the exe?

[Shield]

No, I'm asking what you plan to do, maybe there is a safer solution.

[SPP]

Only save partial data of a configuration file in a secure way.

Regards,

[Inf0Byt3]

You don't need to store the key inside, just the IV. Storing the key inside would create a security hole as it could be read with ease by others. What you can do depends on what you are trying to achieve.

For example, if you want to encrypt resources, images, sounds, etc. inside the exe and load them later, you could store the key in such way that it is generated with your own algorithm at program run time. Or store a number inside and derrivate the original key from it.

If you want to encrypt files or data that you want the user to decrypt later (for example a file encryptor or password manger), then you could store the MD5 or CRC32 of the original, unencrypted data inside the file itself. After the user inputs the password, calculate CRC32 again from the decrypted data and compare it with the one in the file. This is pretty secure, as the key is not inside the file, the attacker only knows the CRC32 of the data which is not very concludent.

[SPP]

Inf0Byt3, thanks for your time ,

I take note of your suggestions. These are welcomed; now is all more clear.

Regards