# 02.22.2022 - Security/How Bitwarden encrypts your data

This note only covers the mechanism of Bitwarden's end-to-end encryption for a single user, between one or more clients. For more information about how they handle user authentication and password sharing, you should check their [Security White Paper](https://bitwarden.com/help/bitwarden-security-white-paper/).

At a high level, Bitwarden is a password manager that has two main parts: **The Server**, and **The Clients** (Web Vault, Browser Extension, Desktop, and Mobile apps,...).

The Bitwarden Server is essentially a REST API that only stores encrypted data sent from the clients. It has almost nothing to do with data encryption (more on this later). All the data encryption, decryption, key derivation works are done by the Bitwarden Clients.

This model ensures all your sensitive data are fully encrypted everywhere outside of your device (during transmission, on Bitwarden's server,...). Without your Master Password, no one will be able to decrypt your data, even the people with DB access.

---

Everything starts with your Master Password when you create a Bitwarden account. The Bitwarden Client will generate a number of keys to be used for data encryption and user authentication:

![](_meta/bitwarden-key-gen.png)

A 256 bit **Master Key** is created by applying [PBKDF2-SHA256](/everyday/02-21-2022-security-cryptography-pbkdf2) with 100,000 iteration rounds, the Master Password, and the user's email address (as a salt).

This Master Key is then additionally stretched to a 512 bit **Stretched Master Key** using HMAC-based Extract-and-Expand Key Derivation Function (HKDF).

$$
\text{Master Password} \xrightarrow[\text{Salt = Email Address}]{PBKDF2-SHA256} \textbf{Master Key} \xrightarrow{HKDF} \textbf{Stretched Master Key}
$$

Additionally, a 512 bit **Symmetric Key** and an **Initialization Vector (IV)** are also generated using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG).

The Master Key will be used for user authentication. The Symmetric Key will be used for vault data encryption/decryption.

The Symmetric Key also gets encrypted using AES-256, with the Stretched Master Key and the IV to create the **Protected Symmetric Key**, which will be sent to the server for later use (more on this later).

![](_meta/bitwarden-protectedsymkey.png)

---

Vault items (like logins, cards, notes,...) are encrypted using AES-CBC 256 with your Symmetric Key. The encrypted items are called Ciphers, will be stored on the Bitwarden server.

![](_meta/bitwarden-vault-encrypt.png)

Any requested items from the server are sent to the client as a Cipher, and the decryption also happens on the client only.

---

Only the Protected Symmetric Key is stored on the Bitwarden server and will be requested by the Bitwarden Client if needed. The Master Password, Master Key, or Stretched Master Key are never stored anywhere (locally or on the server).

The Symmetric Key is stored locally **in the memory** only when your Vault is unlocked because it is needed to decrypt data. When the Vault is locked, this data is purged from the memory.

When you unlock your Vault, you will be asked to enter your Master Password again, and Bitwarden Client will repeat the process described in the previous section to obtain the Stretched Master Key. The Protected Symmetric Key will be decrypted using Stretched Master Key to obtain the Symmetric Key.

![](_meta/bitwarden-decrypt-symkey.png)

The same when you log in to Bitwarden from another device or another client, only the Protected Symmetric Key is sent to the new client from the server, all the necessary keys are derived from this key and your Master Password.

![](_meta/bitwarden-multiple-devices.png)

---

When you change your Master Password, there is an option to rotate Encryption Key, and it's not enabled by default. This means Bitwarden doesn't need to re-encrypt all your Vault items when you changed the Master Password. It might seem obvious at this point, but if you missed it and asked how's that possible, here's why:

- The key that is used to encrypt your Vault data is the randomly generated **Symmetric Key**.
- This Symmetric Key is encrypted using the Stretched Master Key (which is derived from your Master Password) to create the **Protected Symmetric Key**.
- When you change your Master Password, you get the new Stretched Master Key, and only the Protected Symmetric Key needed to be re-generated, the Symmetric Key remain unchanged.
- So, your encrypted data does not need to be re-encrypted. In fact, the encryption has nothing to do with your Master Password.





How Bitwarden encrypts your data

# 02.21.2022 - Security/Cryptography/PBKDF2

PBKDF2 is a key derivation function, used in the process of deriving encryption keys.

The main idea of PBKDF2 is repeatedly applying the input and the salt to a hash function like HMAC to produce a key, which can be used later on in subsequence operations.

Passwords managers like 1Password and Bitwarden use this function (in a combination of a much more complex scheme) with your Master Password to generate a symmetric key for encrypting and decrypting data in your vault.

The PBKDF2 function takes several input parameters and produces the derived key as output:

$$
\text{Output} = \text{PBKDF2}(\text{PRFn}, \text{Password}, \text{Salt}, \text{N}, \text{KeyLen})
$$

where:

- $PRFn$ is a pseudorandom function that produces an output length $hLen$ bits, for example, keyed HMAC.
- $Password$ is the input password
- $Salt$ is a securely generated random bytes, minium 64 bits but 128 bits is recommended
- $N$ is the number of iterations of HMAC derivation. For example, in Bitwarden, it's 100,001 iterations
- $KeyLen$ is the expected key length for the output, for example, 32 bytes (256 bits)

The iterations count is directly proportional to the time it takes for key derivation. The slower key derivation, the slower login time but the password is more secure against cracking attacks.

The $Output$ is the concatenation of many $hLen$ bit blocks:
$$
\text{Output} = T_1 + T_2 + ... + T_{\text{KeyLen} / \text{hLen}}
$$

Each block $T_i$ is computed as:

$$
T_i = F(\text{Password}, \text{Salt}, \text{N}, i)
$$

The function $F$ is the XOR of $Count$ iterations of chained $PRFn$. Chained mean, the later iterations will use the computed result of the previous iteration as an input:

$$
F(\text{Password}, \text{Salt}, \text{N}, i) = U_1 \oplus U_2 \oplus ... \oplus U_{\text{N}}
$$

Where each $U$ is:

$$
U_1 = \text{PRFn}(\text{Password}, \text{Salt} + \text{Int32BigEndian}(i))
$$

$$
U_2 = \text{PRFn}(\text{Password}, U_1) \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad
$$

$$
...
$$

$$
U_N = \text{PRFn}(\text{Password}, U_{N-1}) \quad \quad \quad \quad \quad \quad \quad \quad \quad
$$

The $Output$ is extracted as the first $KeyLen$ bits of the final hash.

---

It's important to note that PBKDF2 is not resistant to GPU attacks for ASIC attacks (attacks using specialized hardware). For new systems, it's recommended to use a more secure algorithm like **Bcrypt**, **Scrypt**, or **Argon2** instead.

**What's next?**

- https://bitwarden.com/help/bitwarden-security-white-paper/
- https://1passwordstatic.com/files/security/1password-white-paper.pdf

Cryptography PBKDF2

# 02.07.2022 - Security/Timing Attack and Constant-time Compare Algorithm

**Timing attack** is the type of attack when an attacker tries to analyze the time it takes your application to do something, in order to guess the data it's operating on.

For example, you build an API and try to secure it by checking if the access token matched with some secret token:

```typescript@focus=3:7
const verifyAccessToken = (request: RequestData) => {
    const token = request.header['AccessToken'];
    if (token == SECRET_TOKEN) {
        return true;
    } else {
        return false;
    }
};
```

By doing this, your code is vulnerable to timing attacks. The reason is, for most languages, string comparison algorithm works like this:

```
compare(s1, s2):
    if len(s1) != len(s2) then
        return false
    else
        for each character (c1, c2) in (s1, s2)
            if c1 != c2 then
                return false
    finally
        return true
```

The algorithm iterates over each character of the two string, and stop right after it found the difference. So, different inputs will take different amounts of time to run, depending on the location of the first difference.

Using the time difference, the attacker can guess what's inside the secret token. For example, if comparing each character takes 1µs, and some complete mismatch input will fail immediately:

```
Time taken: 0µs

S E C R E T
^
D O N U T S
^
```

Then, the attacker found that input starts the letter `S` takes a slightly longer time to return, they know that the letter `S` exists in the secret code:

```
Time taken: 1µs

S E C R E T
  ^
S O N U T S
  ^
```

Repeat this process for the remaining letters somehow, they can guess their way to the final secret:

```
Time taken: 4µs

S E C R E T
      ^
S E C U R E
      ^
```

So, it's necessary to avoid variable-time comparison algorithms like this when comparing secrets, instead, we should use constant-time comparison algorithms, these algorithms take the same amount of time to run regardless of the location of the difference in the input.

```
constant_compare(s1, s2):
    if len(s1) != len(s2) then
        return false
    else
        result = 0
        i = 0
        while i < len(s1) and i < len(s2)
            result |= s1[i] ^ s2[i]
            i++
        return result == 0
```

**What's next?**

- https://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf
- https://codahale.com/a-lesson-in-timing-attacks/
- https://bryanavery.co.uk/cryptography-net-avoiding-timing-attack/
