Encryption at Rest vs in Transit vs End-to-End Encryption

You upload a private note to a website. Its address starts with HTTPS, and the service says it stores encrypted data. Does that mean the service cannot read your note?

Not necessarily. Encryption in transit protects a connection. Encryption at rest protects stored data. End-to-end encryption concerns which endpoints can decrypt the content. These protections can work together, but each answers a different question.

Understanding the difference helps you choose a sharing method without treating every encryption claim as the same promise.

The differences at a glance

The first two describe where protection applies. The third describes the trust boundary. The fourth is an access rule.

What is data encryption in transit?

Data is in transit while it moves between systems: a browser uploads a note, an application sends an API request, or a server transfers a file.

On the web, HTTPS uses Transport Layer Security, or TLS. It protects traffic between a client and the server terminating that connection, helping prevent outsiders from reading or silently changing it. Server authentication also helps the browser establish that it has connected to the expected site. Mozilla's TLS documentation explains these separate roles.

The boundary matters. If a browser sends a note over HTTPS to an application server, that server can receive the note in readable form. If a reverse proxy terminates TLS first, protection for its next connection to the application must be considered separately.

For example, encrypting a browser upload does not determine whether the application later saves the note as plaintext or ciphertext. HTTPS is essential connection protection; it does not answer the storage question.

What is encryption at rest?

Data is at rest when it is saved: on a laptop, in a database, in object storage, or in a backup. Encryption at rest transforms that saved information into ciphertext that requires the appropriate key to recover.

There are different layers. Disk encryption protects storage media; application encryption can protect individual content fields before they reach the database. Neither phrase alone tells you who holds the keys or what an authorized application can read.

NIST's storage security guidance, section 4.9, distinguishes storage encryption from other controls. It explains that infrastructure encryption can help with lost or stolen media while offering limited protection when an attacker gains access through an already authorized system.

Consider a stolen database export. Application-encrypted note bodies can remain unreadable without their keys. But if someone compromises the running application and obtains the required decryption capability, encrypted storage alone may not protect those notes.

Ask about copies, too: backups, exports, temporary files, and metadata can have different protection and retention rules.

What changes with end-to-end encryption?

In end-to-end encryption, the sender's endpoint encrypts the content and the intended recipient's endpoint decrypts it. Delivery servers carry the encrypted content without having the keys needed to read it. The IETF's Messaging Layer Security specification describes this distinction between communicating endpoints and delivery servers.

For a sharing service, the practical question is: can the service decrypt the content during normal operation? A statement such as “encrypted with AES” does not answer that. AES names an algorithm, not where encryption happens or who controls its keys.

Client-side encryption is relevant, but that label also needs context. If a client encrypts a document and then sends its decryption key to the provider, the provider's access has not been excluded merely by moving the encryption step into the browser.

E2EE still has limits. Once the recipient opens a message, malware, screenshots, copying, or someone looking at the screen can expose it. It also does not automatically hide all metadata or make every backup end-to-end encrypted.

Where do passwords and one-time links fit?

A password gate decides whether a request is allowed to reveal content. A one-time limit decides whether another reveal is allowed. An expiration decides when access closes. These controls can accompany encryption, but they do not replace it.

Imagine an encrypted note with a one-view limit. After the first successful reveal, the service rejects another opening. That does not tell you whether its encrypted record or backups were erased, and it cannot take back a copy the recipient already made.

These are useful controls when your goal is to reduce repeated access through a shared link. If your requirement is that the provider cannot decrypt your content, evaluate the encryption architecture separately.

How this applies to LOCK.PUB private notes

LOCK.PUB's private-note flow uses server-side encryption. The application receives the note and password, encrypts the protected note before storing it, and decrypts it on the server during unlocking. The server checks the password and access rules before returning the note. This memo flow does not exclude the service from plaintext processing and is not end-to-end encrypted.

The private note tool provides a password-protected link. Keep sensitive text inside the private note field: the public label is visible before unlocking.

The One-Time Secret tool adds one successful reveal, then blocks later reveals through that link. Its promise is one-time access, not automatic deletion. Send the password through a separate channel when the note is sensitive, and verify the recipient before sharing.

For a broader handoff checklist, see how to share passwords securely.

Questions to ask before sharing

Start with your actual requirement:

• To protect network traffic, check that the relevant connections use HTTPS or another appropriate secure transport.
• To protect stored copies, ask what is encrypted and who can decrypt it.
• To exclude the delivery provider from content access, look for a documented end-to-end design.
• To limit later openings, check the tool's password, expiration, and view-limit behavior.

Also protect the receiving device. The UK NCSC's guidance on data at rest and in transit treats stored data and transmitted data as separate protection needs. A secure connection cannot compensate for an exposed copy on an unlocked device.

Does HTTPS mean a note is end-to-end encrypted?

No. HTTPS protects the connection to its TLS endpoint. The application may still receive and process readable content.

Can a service use encryption at rest and in transit together?

Yes. It can protect network connections and saved copies while retaining the ability to decrypt content for authorized use.

Does opening a secret once delete every copy?

No. A one-time access rule restricts later reveals. Deletion, backup retention, and copies made by recipients are separate questions.