Two different moments
Data spends its life in two states: moving between machines and sitting in storage. Encryption for each state answers a different question.
- In transit: can someone on the network, such as a Wi-Fi operator, an internet provider or an attacker on the path, read or change data while it travels?
- At rest: can someone who gets hold of the storage itself, such as a lost laptop, a stolen phone or a copied disk, read the data on it?
A system can do one well and the other badly. A website served over TLS that writes its database to an unencrypted disk is protected in transit and exposed at rest. A phone with full storage encryption that sends data over plain HTTP is the reverse.
Encryption in transit
The standard tool is TLS, specified for version 1.3 in RFC 8446. Its stated goal is a secure channel between two communicating peers, with three properties:
- Authentication. The server is always authenticated, and the client optionally.
- Confidentiality. Data sent over the channel is visible only to the endpoints.
- Integrity. Attackers cannot modify the data without being detected.
The RFC says these should hold even against an attacker with complete control of the network. It is also clear about a limit: TLS does not hide the length of the data it transmits, although endpoints can pad records.
The important word is endpoints. TLS protects one hop, from your device to the server it connects to. The server decrypts the data, and whatever it does next, such as storing it or passing it on, is outside that channel. When a message passes through several servers, each hop needs its own protection and each server sees the content. End-to-end encryption moves the endpoints to the sender’s and recipients’ devices, so the servers in between carry data they cannot read.
Encryption at rest
NIST Special Publication 800-111 describes storage encryption as using encryption and authentication to restrict access to and use of stored information. It starts from the threat that information stored on end user devices, such as laptops, smartphones and removable media, could be accessed by unauthorised parties. It describes three types of solution: full disk encryption, volume and virtual disk encryption, and file or folder encryption.
Current phones encrypt at the file level.
- iPhone and other Apple devices. Apple’s Data Protection creates a new key for every file as it is created and uses the hardware AES engine to encrypt the file as it is written to flash storage. Each file is assigned a protection class that decides when its key is available, and Apple says third-party apps receive this protection automatically.
- Android. Android supports file-based encryption, which lets different files be encrypted with different keys, and requires it on devices launching with Android 10 or higher. Each user gets Credential Encrypted storage, available only after the user has entered their credentials, and Device Encrypted storage, available during Direct Boot before the user has entered credentials as well as afterwards. The Android documentation says files should live in Credential Encrypted storage whenever possible.
At rest encryption is only as strong as the protection of its keys. On phones those keys are tied to the passcode and to hardware, which is why a locked phone protects more than an unlocked one. See what happens when a phone holding keys is lost.
Where each one stops
| Situation | Encryption in transit | Encryption at rest |
|---|---|---|
| Someone reads network traffic | Protects content and integrity, not data length | Does not apply |
| A device or disk is stolen while off or locked | Does not apply | Protects, if the keys are not available |
| A server operator reads stored data | Does not apply | Not if the server holds the keys |
| Malware runs on an unlocked device | No | No |
Neither one protects data while software that can decrypt it is using it. Encryption also does not hide everything about the data: who talked to whom, when and how much can remain visible, which is a separate problem from encrypting the content.
Messaging apps need both
End-to-end encryption protects a message on its way, but the receiving app decrypts it to show it, and often keeps it. RFC 9750, the MLS architecture document, notes that applications often retain unencrypted messages, so an attacker with access to the device may not need to break the encryption at all. It recommends protecting stored messages with encryption at rest, with keys kept in the device’s dedicated secure storage, and deleting messages as soon as practical where the threat model calls for it.
Storage also has a lifecycle that encryption alone does not manage. The Offline Protocol security documentation notes that on iOS, Keychain identity state survives an app uninstall unless it is explicitly wiped, and asks apps to include identity and document deletion in the account lifecycle. Deleting data deliberately is part of protecting it at rest.