> ## Documentation Index
> Fetch the complete documentation index at: https://docs.envsecrets.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Data Model

> Learn how our architecture is designed to secure your secrets.

### 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](https://en.wikipedia.org/wiki/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](https://nacl.cr.yp.to/secretbox.html)'s [secretbox package](https://pkg.go.dev/golang.org/x/crypto/nacl/secretbox) 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](https://pkg.go.dev/golang.org/x/crypto/nacl/box) 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.

<Info>
  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.
</Info>