Unfortunately there's a reason why password managers still require a passphrase. It's simply not secure to store the key anywhere near the secure files.
I'm not saying password managers are perfect--they have their own security issues--but it seems that you're attempting to closely mimic that functionality (except for data instead of passwords) while removing the requirement for a passphrase. I would investigate the security model of some well respected password managers as a foundation to give you some insight/inspiration. I like the idea of storing your key on a flash drive--it seems to be the best suggestion here so far, but honestly that probably won't be much more secure than simply writing your passphrase down and keeping it in your wallet. Trusting a device or piece of paper also has a steep downside: it can be lost just as easily as your memory--maybe more easily. Depending on a device and then losing it is just as devastating as forgetting the passphrase so this doesn't really meet your requirements given the inspiration behind this project. Storing your password somewhere in the cloud as a backup can be a form of poor mans two-factor authentication/password recovery. You can try to remember the passphrase (or not lose the device/paper), or you can remember your account details for the backup. Gives you two shots at recovery (three if the cloud service has a password recovery option). Please note, however, that the more places you put the passphrase the less secure it is, but it sounds like you need "good" encryption with a near zero percent chance of losing the encrypted data, as opposed to "great" encryption with a high chance of losing the encrypted data. The more secure you need it, the closer you approach needing a brain-memory only long passphrase that is (for some) easily forgotten but impossible to extract digitally. Back to your implementation, I agree with the advice that it's best to keep the passphrase/key separate from the binary. I would start by investigating "non-lose-able" (technical term :P) and reasonably secure methods of storing that passphrase separate from the binary (and even the system that stores the data) as a priority over the encryption software itself. See how that works with existing encryption solutions, and then make the encryption "phase 2" of your project. On Monday, 13 June 2016 23:57:35 UTC-7, as....@gmail.com wrote: > > You're right, even if you aren't planning to share the program, it's still > a good idea to separate the key from the executable. For one, the > executable is bigger and harder to keep secret than a few bytes of data. > It's generally frowned upon to bundle the two since the secrecy should rely > solely on the key. > > If you don't like passwords, you can store the key on a flash drive as a > file or even write it directly to the underlying block device. > > On Monday, June 13, 2016 at 10:12:25 PM UTC-7, Haddock wrote: >> >> Thanks for all the useful answers. All I want to do is to create an >> encryption program for simple home computing purposes. I once lost some >> encrypted files, because I lost the password. I think I did a typo when >> typing it in and didn't realize. So I thought I write my own encryption >> programm with a catch-all password in it. That might be a very bad idea now >> ... >> >> I first wanted to use Java as I'm used to it. But Java code cannot be >> encrypted to hide the encryption key, because the Java byte codes would >> then become unreadable for the JVM. So I thought of something else. I >> thought of moving the key to some server. But then I would be dependent on >> some server and the Internet being reachable in order to decrypt my things >> (password files, etc.). >> >> Seems like the best solution would be to store the key in a separate >> file, though I don't understand exactly how this makes things better. >> Having the key in a separate file means that the decrypted blank key is >> only visible from within the running encryption programm for a very short >> moment. Is that the idea? Maybe have a solution that first looks for a >> local key file and only checks some server for it when locally not present. >> >> Regards, Haddock >> >> Am Montag, 13. Juni 2016 18:01:48 UTC+2 schrieb Haddock: >>> >>> Hello, >>> >>> I'm developing my own little encryption application in Go. The Go >>> application needs to know the key used for encryption and decryption. My >>> question is whether that key can be extracted from the Go executable >>> somehow through disassembly or looking at the applications memory or >>> something. I'm a complete Go beginner and know nothing about its memory >>> layout. So that's why I thought it's better to ask. >>> >>> Thanks, Haddock >>> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
