Encryption

[Nikolay Petrov]

While encrypting/decrypting steams with DES/3DES etc a key is used.
Where should I securely store this key? I guess leve it in code is not
secure. Writing it to file and registry too.
What approach should I take?

Thanks

 

[Crouchie1998]

Some people like to encrypt the key & store it in the registry or you could
encrypt it & store in a XML file in the user's Application Data folder. At
least that way, other users cannot reach it that way.

Crouchie1998
BA (HONS) MCP MCSE

 

[Nikolay Petrov]

but encrypting it also requies as key ;-)

 

[M. Posseth]

Well i store my key in a workgroup file protected Access database
however this also needs a username and password that is compiled in the
executable

so euhhhhhmmmmm yeah

 

[Nikolay Petrov]

Maybe I should describe in more details my needs
I am developing a TCP Client/Server application. I need all transfers
to be encrypted.
The users will get the client exe, so it is quiet easy to get the key,
if it is stored in the exe.
I thought that the client and server could negotiate for key when the
connecto to each other, but this process will not be encrypted, and the
transfered key will be easly intercepted by a packet sniffer.
and besides of that i am new to programming and networking, so you got
the picture.
I am totaly lost.

 

[Stephany Young]

Here's a way we did it using two keys, one 'private' and one 'public'.

1. Encrypt the data using the private key.

2. Embed the bytes for the private key inside the encrypted data.

3. Encrypt the modified data again using the public key.

4. Send the resulting data.

5. Decrypt the data using the public key.

6. Extract the private key out of the decrypted data.

7. Decrypt the modified data again using the private key.

If someone 'intercepts' the data during transmission, the chances of them
successfully decrypting it are practically nil.

Both the sending and receiving executables need to know the public key, but
this is not an issue because of the 'double' encryption.

The private key is hidden in the data and therefore does not need to be
stored anywhere else. In fact, it can be different for every transmission.

The only other things that both executables need to know is where the
private key is 'hidden' and how long it is.

If someone were to 'reverse engineer' either executable, it would still be
possible for them to work out how to decrypt the data, but they will not
find the public key stored in the executables as a constant because it is
not there.

To make it even harder you could use an obfuscator on the executables.

Remember, that if someone really really really wants to crack your
encryption they will. What you are doing is reducing the risk of someone
doing so to an acceptable level.