As Haddock stated, it is basically impossible to prevent it from being accessible to someone looking. Embedding as plaintext will be trivial to extract, and essentially any method you use to encrypt/obfuscate it (encrypt the encryption??) will only be slightly less trivial to extract. Typically not worth the upfront cost/effort unless delaying access to it for a short period of time (not preventing access) has value to you.
I worked in DRM for 5 years we were happy if we could give a tier 1 client 24-48 hours of un-cracked sales (longer for smaller releases). No binary is immune to cracking because at some point, no matter what the obfuscation, the data/code you're trying to protect (like your encryption/decryption key) has to be in memory unencrypted to be usable by the process/CPU/user. Given this, the method of decryption has to exist within the binary, and therefore is accessible to a cracker. With that in mind hopefully it's clear why you can't expect any data/code to be forever inaccessible, and therefore it's not safe to include secrets in the binary. Why do you need to store the key inside the binary, rather than having it stored in some config read by the binary? Can you pass the logic that requires the encryption to a server-side service and then authorize the users in a standard way? With more details on your specific use-case I (or others here) may be able provide guidance towards an alternative solution. This also branches the conversation outside of the realm of Go-specific, so there may be other resources available to you if you think of your question in terms of compiled binaries in general, and not just Go language. On Monday, 13 June 2016 09:01:48 UTC-7, Haddock wrote: > > 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.
