Resources

Security

What protects a vault

A vault is opened by its key, and only by its key. The file itself can be stored anywhere, committed with the code and pushed to your git host; what has to be protected is the key.

Every vault has a public id and a private key. The id names the vault and can be shared; the key opens it. How a vault is encrypted is in Introduction.

The vault key

valt0 init prints a vault's key once, and Valt0 keeps no copy of it.

Byte 1620 has no copy either, and no way to recover a lost key or to reset a vault. A lost key means a vault that no one can open, and a leaked key means a vault that anyone with the file can read.

Give each environment a vault of its own. Each has its own key, so a leaked dev key leaves production alone: see Introduction.

What Valt0 sends

Nothing. The tool makes no network requests of its own: no telemetry, no usage statistics, no crash reports and no update checks.

There is no account and no hosted server. Your vaults, keys and secrets are never sent to Byte 1620.

Read the privacy policy

What runs on your machine

Installing Valt0 puts two things on your machine: the valt0 command, and a service that starts when Valt0 is installed and again at every login.

Your application never opens a vault file itself. It asks the service, through a client, and the service can only open a vault that has been imported into it. A vault you create is imported for you. Introduction has more.

The security chip

Valt0 needs a security chip on the computer you develop on: a TPM on Windows and Linux, or the Secure Enclave on a Mac.

A server or a container that Valt0 is deployed to does not need one. Installation has more on it.

Keys for a deployment

A deployment opens a vault with two keys made for it, never with the vault key: a prime key, used when the application is built, and an unlock key file, used when it starts.

Neither key opens a vault on its own. After it unlocks a vault, Valt0 by default tries to delete the prime key and the primed vault from disk and keep them only in memory. Deployment walks through it.

Secrets in your code

A client hands your code a secret that prints as [REDACTED], in a log line for example, until you ask for its value.

Each client can wipe a secret once your code is done with it. A value taken out as a string cannot be wiped afterwards, so take it out as raw bytes where you can. Clients has the calls for each client.

Report a vulnerability

Report a security problem privately, by email to hello@byte1620.com, never in a public issue.

Please give us the chance to fix it before it is made public. Report a problem has the details, and the same address is in the site's security.txt.