ข้ามไปยังเนื้อหา

Encryption

หน้านี้ยังไม่มีในภาษาของคุณ

Everything bae puts in a cloud home is encrypted before it leaves the device; there is no unencrypted mode. bae implements no cryptography of its own: the entire scheme is coven’s, and this page describes how bae uses it.

KeyWhat it does
The store keyencrypts the library and its membership records
Each person’s circle keyencrypts what that person keeps private: their private play history and playlists
Each file’s keyencrypts one file, and travels only inside its row’s encrypted changes
A person’s signing key pairsigns every change their devices send
A person’s sealing key pairopens keys sealed to that person

The store key is random, made when the library gets its cloud home. A person’s key pairs are shared by all their devices. Private keys and library keys live in the OS keyring, never in a file or the database. They reach a device in two ways, both described in Identity and membership: a restore code carries a person’s own key pairs, and an admin approving an invite seals the store keys to the new person’s sealing key.

A key is never changed in place; a new one is added. After a person is removed, a remaining member’s device adds a new store key, and a new key for every circle they were in, before it writes more data there: everything written afterward is unreadable to them, while the remaining members keep every older key and can read all history. Removing one device rotates nothing, since the person’s other devices share its keys; from the removal on, what that device sends doesn’t count.

Every object in the home: changes, snapshots, membership records, and files. Contents are encrypted with XChaCha20-Poly1305, every change is signed with Ed25519, and keys are sealed to people with X25519 sealed boxes. Files are encrypted in 64 KiB chunks, each authenticated on its own with its position bound in, so a chunk can’t be altered, swapped, or reordered unnoticed. Chunking is why streaming works: the player can decrypt exactly the chunks it fetches.

Object count, object sizes, upload timing, which account writes each object, and which device uploaded each file and snapshot, since their paths name the device. Not names, not metadata, not audio, not artwork. Files sit under random names, never a hash of their content. There is no server-side recovery: if every person loses every device and every restore code, the library is lost, which is the design working as intended.

Opening a library reads its keys from the OS keyring. A keyring that is locked right now, by a locked session or a sleeping display, is told apart from a broken one: bae shows the library as locked and tries again after unlock, rather than reporting the library unusable. A device can also forget the key, which locks the library on that device until it is unlocked again.