4 ms·
This looks very nice. Unfortunately, I think you overstate the security slightly: > After the public key is approved the authority can receive data. The data i
by e12e 4y ago
This looks very nice. Unfortunately, I think you overstate the security slightly:
> After the public key is approved the authority can receive data. The data is encrypted with its public key using OpenPGP.js on the client side and only the cipher (not the original data) is saved to the server. Since the original data never reaches the server we can be sure that even if the server was compromised somehow no sensitive data would be breached.
The server could deliver a backdoor in the client code, no? So it should be quite possible for a hacked/malicious server to steal a user's private key on next use (after breach) of the service?
This isn't a critique of the architecture per se (if upstream is compromised, client compromise is always a risk) - more that it is important to be precise in declaring risks.
- spapas82 4y agoYes, you are right on that. If the server is compromised a malicious user may change the client-side code to add a backdoor and steal your private key when you unlock it. He'll be able to steal only the keys that are unlocked while the backdoor stays undetected (not all the data). The ideal way to resolve that would be to change the service to an API and offer binaries with a correct signature so the user can check and make sure that they get the correct thing. Actually I tried writing the client binaries using electron (https://github.com/spapas/etsd/tree/master/client https://github.com/spapas/etsd/tree/master/client) but didn't have the time for that :( You are rigth though, I've added a Risks section to warn for that thingie https://github.com/spapas/etsd/blob/master/README.md#risks https://github.com/spapas/etsd/blob/master/README.md#risks