Link to home
Start Free TrialLog in
Avatar of Ron Malmstead
Ron MalmsteadFlag for United States of America

asked on

Encryption - Storing the salt in compiled vb.net code....safe ?

Simple question....I can't seem to find a credible answer to.

I've created a client server program that uses md5 + 3des encryption.  I have stored a salt in the code, which gets concatenated onto the original key before hashing, then the message is encrypted using the hash of the salt + key + salt.

My question is.... how safe is the salt ?  After compiling this into an executeable....would someone be able to "decompile" it and find out what the salt is ?

My guess is no.... otherwise no encryption would ever be truly secure.  Knowing the salt or being able to fully decompile the code would allow someone to create a hash database and make any app insecure.

The app is very security sensitive.  It has to be as close to 100% secure as possible.

Does anyone have any credible input on this ?  How safe is the compiled code, and are there code obfuscation methods I should be employing ?
ASKER CERTIFIED SOLUTION
Avatar of JonasMalmsten
JonasMalmsten
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
the salt shouldn't be fixed but random. The random seed should be based in timer or other technique.
The strenght of a cypher algorithm is not increased by hidding it. Modern algorithms are intrinsecally secure because of the cyphering technique itself, and the number of bits, which demands a long period of time (centuries) to be cracked by brute-force techniques.
About 3DES, it is not so secure nowadays. You should use at least 256-bit schemes, like AES (Rijndael).
Avatar of Ron Malmstead

ASKER

....ok, I kind of get what you are saying.  But since they can't get the original source code, how would they get the string ?

Let's say the string looks like this...   Ci-LIL@dk10v23nj-q9vin#KQJ#Lbvj-0893m=
Would the actually be able to figure that out ?
please explain where the key come from...
Salt is used to secure the message, not the key. Unless the key is wrapped by another key, like in PGP.
How could it be random and still work on both ends of the client server app ?
Or do you mean ..it should change programatically ?
jaime_olivares: the salt is basically... "made up"... I made it up.  It exists in both the client and server apps.  Using the client and server, the user provides the key, which in the code is concatenated with the salt.  That combination is Hashed Md5 and is the actual key used in the 3des algorithm.

My question is...   is there a way someone could find out what i've chosen for a salt ?
Yes, it doesn't matter what the string looks like. They can for example start your program with a key they provide. Since they know what the key looks like they can locate it in the computers memory (a low level debugger has full access to all system memory). Then place a break point that will stop program execution every time that mamory location is being accessed. Once you concatenate it with the salt, they have it.

If you are using an external library to compute md5 or 3des it may be even easier. Simply place a breakpoint at the entrypoint to this library and watch what parameters are sent in.

About the salt. If you are using it to prevent a ready made dictionary attack it may be better to randomize a new salt for every session or with regular intervals and send it in clear text to the server. Every time you change the salt an attacker will need to construct a new dictionary which is very time consuming. Or why not use XOR on this salt with the one you have build into your executable, now they must both generate new dictionaries and crack your executable :)

Then again, the hardest part about security may not be the encryption, but the authentication and protocol used to relay the data. Why not use something already existing like SSL or tunneling all traffic through SSH?
Why not use something already existing like SSL or tunneling all traffic through SSH?
agree. you don't have to reinvent the wheel. this is a common security scenario.
JonasMalmsten / Jaime

Really there is not communication for the server to client.... it's simply messages that are encrypted to cyphertext before being sent over a tcp or udp socket connection to the server.  There's really nothing to "hack" into, except a sniffer would be able to pickup the ciphertext.  I just wanted to make sure that nobody would be able to decode it on their own....EVEN IF they knew what the key was...because they wouldn't know the salt or where and in what fashion it was added to the original key.

So basically you guys are both saying.... that a compiled executeable, someone would be able to find out >>>  dim strsalt as string = "foo" & strkey & "bar"   They can't see the actual line of code, but they can get the string value somehow using kernel debuggers........ right ?
Jonas.... are you from Sweden ? ,and is Malmsten your actual last name ?
I know this is "off topic"... but we seem to have a similar last name.  I've never met anyone with such a simliar last name as me.... so I just have to ask.

My last name is Malmstead..., and my ancestors are from Sweden...


How small of a world would it be, if we shared common ancestors ?
It is possible :), but my name is quite common in Sweden.
Cool....

It's not common at all in the US...which is why I asked.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
oh..... ok ... I think I get it now...

I should A) use the salt with the message, not the key, then strip it off after decoding....and B) the salt should change programatically somehow...as long as it will always match on both ends (client/server)

Thanks.
Thanks.