Dane Schneider


Engineer/designer/product. Founder @EnvkeyConfig - simple, secure #secrets & #config. Tweeting #rails #reactjs #golang #encryption #security #ux #design #devops

@marckohlbrugge Good question - I'm planning to do a writeup on the details soon. The end-to-end encryption design is quite similar to ProtonMail's. They have a good overview here: https://protonmail.com/security-details

All encryption is based on the OpenPGP standard, using both OpenPGP.js and Golang's OpenPGP implementation compiled to native extensions for client SDKs.

For each user and server, the server stores both a public key and password-protected private key. The server never sees the password, so the strength of the encryption from the server's perspective is effectively the strength of the password. For the web client, this is a user-supplied password (with lots of prodding to make it a strong one). For servers and local development keys (used by the SDKs), it's a 14 character random alphanumeric string securely generated on the client.

The usual caveats about web encryption do apply (which is why native apps/extensions are also in the works), but the in meantime, Envkey mitigates these issues with every technique currently available. Envkey's web client loads no 3rd party content and maintains a strict content security policy, drastically reducing the risk of XSS attacks. All assets, including the root document, are served statically by a CDN server, not dynamically, further reducing the surface area for a JS-based attack. On top of this, we are rigorous about back end security, so the end-to-end encryption, while solid, is only the outermost layer of protection. Data at rest is also encrypted with our own keys and only our load balancers are accessible to the public internet.

I hope that helps. Let me know if I can provide more info or clarification on anything!

@Danenania Wow, great job on the reply. Sounds like you know what you're doing :)