We’re rewarding the question askers & reputations are being recalculated! Read more.
2 replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
source | link

Ultimately, none of this will entirely prevent you from hiding malicious code in your program (even if the user personally reviewed the code before compiling it, there could still be a Thompson hackThompson hack in the compiler itself), but it does make it more likely that you'd get caught if you tried it.

Ultimately, none of this will entirely prevent you from hiding malicious code in your program (even if the user personally reviewed the code before compiling it, there could still be a Thompson hack in the compiler itself), but it does make it more likely that you'd get caught if you tried it.

Ultimately, none of this will entirely prevent you from hiding malicious code in your program (even if the user personally reviewed the code before compiling it, there could still be a Thompson hack in the compiler itself), but it does make it more likely that you'd get caught if you tried it.

    Post Migrated Here from stackoverflow.com
1
source | link

How could users be sure that my application uses the public key of the recipient? I still could encrypt the message with my own key, intercept it and forward it with the recipient's public key. To withstand tests by security experts, I could do that only on specific users or at specific times.

To some extent, users will always need to trust the people supplying any crypto software (and any libraries and OS components used by the crypto software, or running alongside it) they use.

You can somewhat mitigate this issue by publishing the source code of your client software, inviting security experts to review it, and encouraging users to compile the software from the source. You can publish SHA-2 hashes of the source code (and binaries, if you distribute any) to let users verify that the source code they downloaded is the official reviewed version, and encourage users to share and compare the hashes to ensure that you're not sending different hashes to different users.

Ultimately, none of this will entirely prevent you from hiding malicious code in your program (even if the user personally reviewed the code before compiling it, there could still be a Thompson hack in the compiler itself), but it does make it more likely that you'd get caught if you tried it.

I'm at the point where I think that it's impossible to encrypt and share data securely in the same app. Thus users have to encrypt data in another app and copy it manually into the sharing app.

Most of these trust issues will still be present even if the encryption and sharing functions are separated.

The main advantage of doing so is that, with a separate encryption app, the user could, in principle, run it in a sandbox that is not allowed to communicate with anything else, except for reading the plaintext and writing out the ciphertext (or vice versa). This would make it somewhat harder for the app to open a covert channel to transmit the data to a third party — although, without a detailed manual examination of the ciphertext, it's hard for the user to rule out the possibility of the encrypted file itself containing extra information or deliberate weaknesses to allow someone other than the intended recipient to decode it. Also, in practice, it's unlikely that most users would actually bother running the encryption software in such a sandbox.

Another advantage, of course, is that splitting the encryption and sharing code into separate applications means less security-critical code to review: if the sharing app never sees the unencrypted data, and cannot control how it's encrypted, it does not really need such detailed scrutiny. Also, if the encryption and sharing software is provided by different parties, it's somewhat less likely that they would collude to compromise the security of the combined software (although just compromising the encryption app might well be enough).

Ultimately, it does boil down to trust. You can do various things to encourage trust, and to limit your own ability to break it, but you can't eliminate it entirely.

What I would do in your position, to minimize my own ability to compromise the software, would be to:

  • Open-source your application, and publicly invite independent security reviews.

  • Encourage users to compile your application from the source.

  • Distribute SHA-2 sums of all the source code (and binaries) you release, both on your web page, within the release packages, on mailing lists and via any other channel you can think of. Encourage your users to share and compare these checksums from multiple sources, and to complain publicly if they don't seem to match.

  • Possibly provide a baseline encryption feature in the program, but clearly note that this may not be fully secure, and encourage your users to use additional encryption (of their choice) on top of that.

  • Separate any built-in encryption code, and any other security-critical parts of the code into separate programs. Even if these helper programs were automatically invoked by default, to provide an integrated user experience, it should be possible for the user to invoke each of them separately in an isolated environment.

  • Not use on-demand code distribution (e.g. in-browser JavaScript) or any kind of automatic update mechanisms: these make it very easy to deliver compromised code to specific users (e.g. in the guise of a bug-fix update). Alas, avoiding these mechanisms also makes it harder to distribute legitimate bug fixes to users, so there's a tricky security tradeoff here.

    The best you can probably do here is to either a) distribute updates through a channel the users already trust, and which preferably involves at least some external review, such as the system package manager on Linux, or b) poll for updates (over SSL), but don't download them automatically; encourage your users to verify via external channels that there really has been a legitimate update (and to do the SHA-2 sum checking described above) before installing the update.

  • Accept that, no matter what I do, there's always the possibility that the software could be compromised. Also accept that, in practice, most users will not care, and will be content to trust you, whether they should or not.