Encrypt, Decrypt without a hard-coded password

I am trying to find a technique to encrypt and decrypt a file in a program without hard coding the password into the program and without asking the user for it.

It would be nice if I could also decrypt the file from another program that I also am writing.

So far I haven't had much luck finding a good technique that looks secure enough for my liking.

I'm writing this in c# but the language isn't important I just need someone to point me in the right direction towards an a开发者_运维问答lgorithm/technique.

This is a recurring problem with no safe real solution. If you want to be able to encrypt/decrypt something safely, you need a key. Your program needs to know that key. If the key is stored, somebody else can find it and use it to access your encrypted data.

Think of it like this: If your program should be able to access the encrypted data without hard coding the key into the program and without asking the key from the user, then why can't any other program do the same and acquire the encrypted data?

I think you need to define the problem further before you are ready to talk about how to code it.

Specifically, who should be able to decrypt the data? And what technique would you use to prevent others from doing it.

As it stands, the question may was well be "I'd like a lock on my door that doesn't require a key." The statement hasn't really defined the goal with enough clarity.

Put a web resource up with the password on it, and have the code request that web resource. Of course, to do this securely involves SSL and a webhost, but it fits your needs.

If your program features user accounts with their own passwords, you could do something like:

1. Set up a users table containing a column for storing an encrypted copy of the program-wide password.

2. Encrypt a copy of the program-wide password in each user's account using the user's password as the key.

3. When the user logs in, the system password is decrypted using their password and stored as a session-length cookie (SSL only) on their browser.

In this way, each user can get a copy of the system password silently in the background.

HOWEVER, this approach has some serious drawbacks.

First, the system password becomes no more secure than the WEAKEST user password. If Bob from Accounting sets his password to "password123", then that can be used to retrieve a copy of the system password.

Second, an attentive attacker will notice that cookie contains the system password, and then you're screwed.

You could obviate that by actually storing the decrypted password on a third machine accessed via SSL, then retrieve it for each transaction based on the user's session ID; but this would mean if the third server goes down for any reason, your entire system is down. It would also impose performance penalties, and your data server's security would depend on the password server's security.

And after all that convolution, in the end there's no really good solution; you just have to either prompt them for the password or store it on the server itself and lock the server down as tight as you can.

In cryptography the strength of the encryption scheme is the function of secrecy and strength of the key. This means that the key must be secret (i.e. not accessible to the attacker). Now, if there key is not in user's hand and not in the application code, where it is? And how secret it is?

So you need to re-think your task. Maybe good obfuscation of the key will drive away most not-very-skilled attackers. The simplest way to obfuscate the key is to use some text phrase of your program as a key. This makes operations with the key less obvious for an occasional lurker (professionals know different ways to find the encryption keys in the application).

Maybe the best answer could be a password generated by some means (like the size of a file or any other fixed value in the system). So you store in code the way to obtain the password rather than the password itself.