PasteDB uses trusted devices to securely transfer your account encryption key to a new device without sending your plaintext encryption key to the server.
End-to-end encryption means PasteDB cannot simply give your encryption key to every device that logs into your account.
During registration, your device generates a random account encryption key. The key is kept on the trusted device and is used to decrypt your encrypted pastes.
When you sign in on another device, that device generates its own cryptographic identity. It can authenticate your account, but it cannot immediately decrypt your existing E2EE pastes.
The KEK is an important part of the E2EE decryption process, but it does not directly decrypt the paste itself.
PasteDB uses a layered encryption system. The account KEK is used to decrypt or unlock the PEK, and the PEK is then used to decrypt the encrypted paste. In simple terms:
Therefore, saying that the KEK is used to decrypt E2EE pastes means that the KEK participates in the decryption process indirectly. The KEK unlocks the key needed to decrypt the actual paste.
A device that already has your account KEK can authorize another device.
Trusted device
Has account KEK
Wrapped using Device 2's public key
Uses its private key to decrypt the KEK
Your devices page shows which devices are already trusted and which ones are waiting for approval.
The trusted-device system uses public-key cryptography to transfer the account KEK.
When a device registers, it generates a public key and private key. The public key can be shared with the server, while the private key remains on the device.
The device sends its public key to PasteDB. The server associates that device with the user's account.
A trusted device can see the new device in the account's device management page.
The trusted device takes the new device's public key and uses it to encrypt the account KEK.
The server stores the wrapped KEK associated with the target device. The QR code contains a link that identifies this transfer.
The link opens the transfer page. The page requests the encrypted KEK associated with that device.
Device 2 uses its private key to decrypt the encrypted KEK. The resulting KEK is then stored locally for decrypting the account's E2EE pastes.
The important idea is that the trusted device does not need to expose the plaintext KEK to the server.
The key used to decrypt your encrypted pastes.
Used by the trusted device to wrap the KEK for the new device.
Remains on Device 2 and is used locally to unwrap the KEK.
The QR code is simply a convenient way to transfer the approval link from one device to another.
The QR contains a PasteDB transfer URL. It does not contain the plaintext account KEK.
PasteDB can store the device public key and the encrypted KEK required for a trusted-device transfer. The target device's private key remains local and is required to decrypt the wrapped KEK. This allows a trusted device to authorize another device without simply handing the account encryption key to the server.