Che cos'è la crittografia end-to-end? Una definizione crittografica

Encryption is not the same as end-to-end encryption

Most serious web services use TLS. That matters: TLS protects data while it travels between your browser and the server, and it prevents local-network attackers from reading the connection.

But TLS terminates at the server. Once the request arrives, the service can usually see the plaintext. The provider may then store it, scan it, index it, process it, or encrypt it again at rest with keys the provider controls.

That is encrypted transport. It is not, by itself, end-to-end encryption.

The cryptographer's definition

A precise definition of E2EE starts with key possession. In a true end-to-end system, encryption and decryption keys are created and held by the endpoints, not by the delivery service.

The server can route, store, rate-limit, and delete ciphertext. It can operate the service. But it does not hold the key material required to turn ciphertext back into readable content.

Matthew Green's well-known analysis of Zoom's encryption controversy makes this point clearly: the core property is not just that encryption exists, but that decryption keys are unavailable to the provider.

• The sender endpoint can encrypt the data.
• The recipient endpoint can decrypt the data.
• The intermediary server only handles ciphertext.
• A server compromise should not expose plaintext content.

Client-side encryption can still fall short

Client-side encryption means the cryptographic operation happens locally before upload. That is necessary for many E2EE designs, but it is not sufficient on its own.

A service could encrypt data in the browser and then upload both the ciphertext and the matching key to its backend. The encryption happened client-side, but the provider still has the key. That breaks the end-to-end boundary.

The meaningful distinction is exclusive key possession. If the provider can access, recover, rotate, escrow, or regenerate the usable key, the user is still trusting the provider with plaintext access.

How URL-fragment notes fit the model

PrivateNote uses a browser-based version of this architecture for one-time notes. The sender's browser encrypts the note locally. The encrypted payload is uploaded to storage. The decryption key is placed in the URL fragment: the part after the # symbol.

Browsers do not send the URL fragment to the server in the HTTP request. That means the server receives the ciphertext, but not the key. When the recipient opens the link, their browser has the fragment locally and can decrypt the note after the reveal step.

This is not the same topology as Signal or MLS, where endpoints are usually account-bound devices with persistent public keys. But the central security property is the same: the storage provider does not possess the key needed to decrypt the content.

The delivery channel still matters

A one-time encrypted link is powerful, but the full link becomes sensitive because it carries the decryption key in the fragment. If you paste that link into a channel that logs messages, syncs history, or is monitored by an administrator, that channel may expose the secret before it is opened.

This is why expiration, one-time reads, and optional passwords are operationally important. They do not change the definition of E2EE, but they reduce the damage if a link is forwarded, logged, or previewed by software.

For highly sensitive material, send the link through one channel and share the optional password through a different channel. That separates possession of the encrypted payload from possession of the human secret.

The offline brute-force caveat

Password protection adds defense in depth, but it has a real cryptographic caveat. If an attacker obtains the full link and downloads the ciphertext before it expires, password guessing can become an offline attack. The server's rate limits no longer help, because the attacker can try guesses against the ciphertext locally.

PrivateNote uses Argon2id for password-protected notes. Argon2id is a memory-hard key derivation function, which raises the cost of each password guess, especially for GPU-heavy brute-force attacks.

That does not make weak passwords safe. A short or reused password can still fail. The stronger the optional password, the more useful this second layer becomes.

Why the architecture matters

E2EE changes the trust model. With ordinary encrypted-at-rest storage, users rely on provider policy, employee controls, legal handling, and breach prevention. With end-to-end encryption, the provider is structurally limited: it can store encrypted data, but it cannot decrypt it.

That does not eliminate every risk. Endpoint malware, malicious browser extensions, copied links, weak passwords, and unsafe delivery channels still matter. Cryptography narrows the trust boundary; it does not remove operational judgment.

The value is still significant: a database breach should expose unreadable ciphertext rather than message content. That is the difference between promising not to read data and being unable to read it in the first place.