​
User

  • Every new user is issued a public-private RSA key pair.

​
Keys Backup

  • We encrypt your private key with a separate symmetric “protection” key. This new “protection” key is in turn protected with your account password using the Argon2 method which can derive cryptographic keys from passwords and was selected as the winner of the 2015 Password Hashing Competition.
  • Now your public key, encrypted private key, encrypted protection key and hashed account password are stored on our servers.
  • Whenever you login from a different machine, your key pair is downloaded from our servers, decrypted locally using your account password and saved in your machine.

​
Organisation

  • Every new organisation is issued a fresh AES 256 bit symmetric key.
  • All secrets in this organisation are encrypted with it’s key using the industry standard NaCL’s secretbox package which uses XSalsa20 and Poly1305 to encrypt and authenticate messages with secret-key cryptography.

​
Collaboration

  • When a new member is invited to your organisation, they are issued a copy of the organisation’s key encrypted with their own (invitee’s) public key using NaCL’s box package which, in turn uses Curve25519, XSalsa20 and Poly1305 to encrypt and authenticate messages. And this copy is stored on our servers.

​
Implementation

​
Authentication

  • Running envs login from the CLI installs your public-private key pair locally after decrypting it with your account password.
  • Running envs init in the project root directory, saves the project configuration in that directory along with installing your encrypted copy of the chosen organisation’s key.

​
Cryptography

  • When a member does envs set KEY=value from the CLI, their locally stored copy of the organisation’s key is first decrypted using their private key, then the secret value is encrypted with the decrypted key. This key-value pair is then uploaded on our servers.
  • Vice versa, when they do envs get KEY, the encrypted secret value is downloaded from our servers and decrypted using the locally stored copy of organisation’s encryption key.

​
External-Syncing

  • At the time of signup, every user is issued a unique 32 byte symmetric “syncing key.” This key is visible and available to the server.
  • When a user decides to sync their secrets forward to third-party services, the server encrypts the user’s unique “syncing” key with their public key and sends it to the user.
  • The user decrypts the received encrypted copy of their key using their locally available private key to obtain the original “syncing” key.
  • The user then encrypts their secrets with this “syncing” key and sends them to the server.
  • The server, which already have access to this “syncing” key, uses it to decrypt the secrets and pushes them to forward to third-party service APIs.
  • This keep the secrets protected in-transit.
This “syncing” key is only used to encrypt the secrets in-transit for the external-syncing method to work.The server does not store the secrets with itself after having decrypted them. This is a completely stateless operation and can be validated by auditing the source code.