It occurred to me that if I could compile a private key in source code, I could prove that log information came exclusively from the application for a given version.

I could do this by releasing the public key and by making sure that for each log entry created the compiled code when running, I include a digitally-signed hash of the log content.

The problem with this approach is that compiled code can be reverse-engineered and there are advanced ways to regenerate source code from byte code in the case of java. Assuming that the compiled code is distributed to the general public and a version of the source code without private key is available in a public repository such as Git, would I be correct in assuming that there is NO secure way: that there is a standard way to crack the private key given the source code being mostly available?

Is there a secure, compiled programming language that is secure enough to protect the compiled private key from reverse engineering? Is Java or any of the virtual machine runtimes secure enough to protect a private key that had been in the source code before being compiled?

1 Answer 1


There is no way to ship the private key as pure data (i.e. no additional hardware) together with the application or inside the application, no matter if it is encrypted or not.

Since it has to be usable by the application all information to use it need to be accessible to the application too. This means in case of an encrypted private key the matching decryption key needs to be somehow accessible.

When shipping this decryption key directly with the application one runs into the same problem as before - how to protect this decryption key. When trying to download the decryption key from some external source one faces the same problem one was trying to solve with the private key - how to proof that is is the expected application which downloads the decryption key.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .