Home/ Questions/Q 7790611
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T21:38:13+00:00

i am planing to write a C# class library which will include my encryption

  • 0

i am planing to write a C# class library which will include my encryption algorithms like RC4, DES. These are single key encryption algorithms.
Now i want the best secure decision to protect my key. Should i put my key hardcoded inside the DLL or should i set my key from my external application which uses the DLL? Which one do you think is more secure when you consider the decompling tools?
Loudly thinking:

  • if the key is hardcoded in my security library and someone find the DLL and import it to his C# application, can he easly decode my chipper data?
  • if the key is not hardcoded in my security library but is set from my external application, someone needs to decompile also my external application to find my key?

Setting the key values from my external application which will use the security DLL seems more secure to me. What do you think?
Thanks.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Hard Coded Key

    If you include the shared/private key in the DLL, then anyone who has a copy of the DLL will have a copy of the key. If your model is to share your application with multiple users, all users will have the same encryption key, and can decrypt anything encrypted by another user. If your application is easily available, then you have to assume the attacker has the application (and therefore the key) as well.

    It also means that all developers will have access to the production encryption key, since they have the source code. QE will also have access, as they probably have access to the binary. Either of these two insider groups will be able to decrypt anythign that your application protects for your customers.

    Is this what you want? It’s generally a bad practice, but it’s worse in some environments than others. For example, if you’re writing code to learn how to write crypto and nothing more, it probably doesn’t matter – just make sure nobody else can use it 🙂 If you’re writing a service, it’s a bad practice and introduces risk, but it’s not the worst thing you could do. If you’re writing something that will be shared to multiple customers, then you defeat the purpose of encrypting by including the key in the binary.

    And it’s not really that hard to generate random data (using a cryptographically strong random number generator), store it in a file, and use that file as your encryption key. My recommendation is go with the separate key.

    Separate Key

    If you ship the key in a separate file, you eliminate all the risks introduced by shipping the key in the binary but you introduce others. Or, stated differently, now that your crypto can do some good, you need to make sure you do it right or it’ll still be useless.

    The key needs to be generated using a cryptographically strong random number generator, so that it’s not predictable. The key needs to be stored securely – the whole path to the key file needs to be protected, and you should consider using a password protected store (like a keystore) to ensure that only users with the right password can access the key. Of course, that last one depends upon your deployment model, and if you need unattended restart. And the key needs to be used securely – constant order operations, don’t act an encryption or decryption oracle, verify integrity of data before semantically parsing it, etc.

    • 0