4 ms·

For anybody that still believes in gpg and is interested in using it to transmit data across his organisation we've built https://github.com/spapas/etsd https:/

For anybody that still believes in gpg and is interested in using it to transmit data across his organisation we've built https://github.com/spapas/etsd https://github.com/spapas/etsd. This is a project that holds the hands of the users of an organisation to help them send gpg encrypted messages. We're using it successfully for almost a year.

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 ago
  Yes, 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

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 ago
Yes, 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