| crypto.rs |
|
9188 |
80 % |
| datastore.rs |
|
5286 |
91 % |
| keystore.rs |
# On-disk layout
All keystore rows live in `lockstore.keys.sqlite`, in the logical
kvstore database `"lockstore.keys"`. Two row families:
- **DEK metadata** at row key `"lockstore::dek::<collection>"`.
Value is a JSON `DekMetadata` (via `utils::bytes_to_value`):
```text
{
"wrapped_deks": [
{ "kek_type": "...", "kek_ref": "...", "wrapped_dek": [<bytes>...] },
...
],
"cipher_suite": "...",
"extractable": <bool>
}
```
- **KEK records** at row key `"lockstore::kek::<type>:<base64url(random_id)>"`.
Value is a JSON record specific to the `KekType`:
[`LocalKekRecord`](crate::LocalKekRecord) for raw AES bytes,
[`PasswordKekRecord`](crate::PasswordKekRecord) for PBKDF2-wrapped
KEKs, [`Pkcs11KekRecord`](crate::Pkcs11KekRecord) for hardware-
wrapped KEKs.
# Threat model for the on-disk layout
The `wrapped_dek` bytes are the only piece encrypted at rest (under
the KEK named by `kek_ref`). Every structural field — including the
`kek_ref` strings — is plaintext on disk, so a plain `sqlite3` dump
of `lockstore.keys.sqlite` is enough to enumerate which KEKs wrap
each collection. The `nsILockstore.listKeks` API surfaces this same
data programmatically; the on-disk format is documented here as a
stable contract for offline tooling. |
66010 |
68 % |
| lib.rs |
|
8209 |
68 % |
| pbkdf2.rs |
|
3423 |
79 % |
| utils.rs |
|
1154 |
100 % |