4 ms·
If I understand correctly, the decryption code was in the server, so the user was providing the password for the private key, and the code from the server was d
by conductor 13y ago
If I understand correctly, the decryption code was in the server, so the user was providing the password for the private key, and the code from the server was doing the encryption/decryption (by server-side or client-side execution, I don't know). This scheme could be backdoored by altering that server-side code. So, why not keep the code on the client-side (like signed, verified browser add-on or native application)? Then there will be no way to get the password of the private key from the user (except by installing a malware with some 0-day browser vuln).
- tptacek 13y agoNote that Chrome extensions can suffer from essentially the same problem, since they can autoupdate. The reason nobody does this, though, is that end-users don't want to install software on their machines. Unfortunately, there is a fundamental conflict between desire to run software off of other people's machines rather than your own and desire for cryptographic security.
- bradleyjg 13y agoThe client would have to be open source in order for that to work. Otherwise they can just force the provider to put a backdoor in the client code. Probably open source with no downloadable binaries would be best. Maybe even better would be something like only pulling off a source control system so there's an easily accessible audit trail. The idea being not necessarily to prevent an evil adversary, but to convince a judge that there's no way to convincingly be an evil adversary.