2026-10-27 - Encryption is easy. Getting someone to send you an encrypted file isn't.
A first-hand experience
For some time now, I have offered ways to receive documents protected by encryption: public keys published according to open standards, and channels designed for confidential contact. Yet, in my experience, I have never received a document encrypted separately by the sender, that is, protected independently of the service used to transmit it. Not even by email.
Documents do arrive, of course. They arrive via WhatsApp, via Signal, by email. Some of these channels protect the message in transit, and Signal and WhatsApp do so with end-to-end encryption. But once received, the document can be read in the app and, if exported or saved, its confidentiality also depends on the protections of wherever it ends up.
Encrypting the channel and encrypting the document are two different things. That distinction runs through this entire article.
The title is deliberately provocative. “Encryption is easy” refers to the availability of the tools: they exist, and many are free and mature. The hard part is something else: getting someone to use them to send us anything.
Why senders don’t use the tools available
The first reason is the simplest. Whoever needs to send a document often doesn’t know that the recipient has a public key, or where to find it. For email, I discussed this problem in my article on
, which lets software automatically retrieve the key associated with an address.
The second is usability. In a 1999 study that remains a reference point, Alma Whitten and J. D. Tygar found that most participants could not correctly sign and encrypt a message with PGP 5.0 within ninety minutes, despite its carefully designed interface (
Why Johnny Can’t Encrypt, USENIX Security 1999
). Tools have improved a great deal since then, but the core issue remains: encryption asks people to make choices (which key, which format, how to share a password) that most users are not used to making.
The third concerns how people perceive the benefit. Senders also benefit from confidentiality, since an exposed document can harm them. But the effort is immediate and visible, while the benefit is shared and and less immediately apparent. When faced with an extra step today and a risk that may never materialize, people tend to take the shortcut.
Then there is the smartphone. In my view, this is the most underestimated limit. People now communicate mostly from their phones, and the security they actually adopt is whatever the app they already use builds in. Encrypting a file separately, picking the recipient’s key, and sharing the result is an obstacle course on a phone, and file encryption often remains easier on a computer. The state of the available tools is examined in the
.
What transport, messaging and file encryption protect
There are three kinds of protection at stake: transport protection, end-to-end messaging and file encryption. They aren’t ranked, and they aren’t mutually exclusive: you can combine them, and they meet different needs. To understand what each one offers, it helps to ask four questions:
- who I want to protect the document from: someone intercepting network traffic, the service provider, someone with access to the device, whoever will store it over time;
- who holds the keys needed to read it;
- what remains visible even when the content is protected;
- what happens to decrypted copies.
TransportEnd-to-end messagingFile encryption
ExamplesTLS connections for websites and email; Italian certified email (PEC); upload linksSignal, iMessage, WhatsAppPassword-protected 7z archive; OpenPGP; age
Typically protects againstAnyone intercepting data as it travels across the networkThe service provider too, as far as content is concernedAnyone without the key or the password, in transit and afterwards
Who holds the keysThe systems at each end of each connection; the provider can normally access the contentThe participants' devicesThe recipient (private key) or whoever knows the password
What remains visibleTo the provider, generally both content and metadataMetadata, to an extent that varies from service to serviceThe file's size and existence; in some formats, the names of the files inside
Decrypted copiesThe provider stores the document under its own rules; whoever downloads it gets a readable copyOn the device the document is readable and may end up in backups, other apps or forwarded messagesCopies of the encrypted file keep their encryption; decrypted copies need protection of their own
The table calls for two caveats. First, we need to distinguish the properties of a technology from the configuration of a service. For example, an upload link does not, by itself, guarantee end-to-end encryption, but some services encrypt the file on the sender’s device before sending it. Likewise, what remains visible in an end-to-end chat depends on each service’s design choices; I have written a
dedicated analysis of WhatsApp metadata
.
Second, none of the three protections holds if the device used to read the document has been compromised. We will come back to this shortly.
Why the difference matters: professional practice and the law
The legal framework is clear, but it needs to be read precisely.
Article 5(1)(f) of the
lists integrity and confidentiality among the principles of processing. Article 32 does not impose a blanket obligation to encrypt every communication: it requires technical and organizational measures appropriate to the risk, taking into account the state of the art, implementation costs and the nature of the processing, and it names encryption among the possible measures.
Article 34(3)(a) relieves the controller of the duty to notify a breach to data subjects where the affected data were protected by measures that render them unintelligible to anyone not authorized to access them, such as encryption. However, it is not enough that a file was “encrypted”: if the key or password was compromised along with the data, that condition is not met.
In my view, when a document contains special categories of data (Article 9) or data relating to criminal convictions and offenses (Article 10), the choice of channel and protections calls for particularly careful assessment, including how the document will be stored afterwards.
Legal professionals also have professional secrecy obligations. In Italy, Article 622 of the Criminal Code punishes, upon complaint by the injured party, anyone who discloses without just cause a secret learned by reason of their profession, or uses it for their own or another’s benefit, where this may cause harm (
Article 622 of the Italian Criminal Code on Normattiva
, in Italian). Article 28 of the Italian Code of Conduct for Lawyers describes maintaining secrecy and the utmost confidentiality about the work performed, and about information provided by the client or learned through the mandate, as both a duty and a right of the lawyer (
Code of Conduct, 2026 consolidated text, National Bar Council
, in Italian).
For entities within the scope of the
, Article 21(2)(h) includes, among cybersecurity risk-management measures, policies and procedures regarding the use of cryptography and, where appropriate, encryption.
Finally, there is a forward-looking reason. Encrypted data collected today could be decrypted tomorrow, once sufficiently powerful quantum computers exist: this is the risk the European roadmap calls “store now, decrypt later”, and it mainly concerns information that must remain confidential for a long time, as many professional documents do. The
, issued in June 2025 by the Member States with the support of the Commission, sets out target dates for the transition: completion by the end of 2030 for high-risk use cases, and by 2035 for as many systems as feasible (
). Which tools already offer post-quantum protection today is covered in the
.
Institutions and messaging apps: three cases
Institutions and government officials already use messaging apps, with documented cases. I chose three because each illustrates a different aspect.
Record keeping and channel governance. In 2022, the UK data protection authority (ICO) found extensive use of WhatsApp and private email by ministers and officials at the Department of Health and Social Care during the pandemic, with inadequate controls. This led to a formal reprimand and a call for a government-wide review of these channels (
). In 2023, the Cabinet Office published
: it rules out these channels for the highest security classifications, asks that significant information be captured in official systems, and allows disappearing messages only where they do not undermine record-keeping obligations. In 2026, the government announced a further review of the guidance (
).
Choosing the channel. In 2020, the European Commission told its staff that Signal was the recommended application for instant messaging with people outside the institution (
). It shows an institution choosing the channel explicitly, rather than leaving it to individual habits.
Device security. In January 2025, WhatsApp said it had disrupted a spyware campaign, attributed to the company Paragon, that had targeted around ninety users, including journalists (
). An Italian journalist at Fanpage.it was among those notified. In a separate episode, Citizen Lab confirmed through forensic analysis that the phone of Ciro Pellegrino, a journalist at the same outlet, had been targeted with Paragon’s spyware through an iMessage vulnerability (
). These cases document attacks on devices, not a break of end-to-end encryption: if one end of the conversation is compromised, the content there is already readable. And encrypting the file separately does not solve this scenario: on a compromised device, the file is exposed the moment it is decrypted, and the key itself can be stolen.
Some may argue that transparency conflicts with encryption. In my view, they operate on different levels. Transparency concerns what an institution must keep and make accessible; encryption concerns who can read information while it travels or is stored. The UK guidance links the two: it acknowledges that end-to-end encrypted messaging is likely more secure than consumer email and social media messaging, but requires significant information to end up in official records. The real conflict comes from elsewhere: private channels, personal devices, and self-deleting messages. Case T-36/23, on access to text messages between the Commission President and Pfizer’s chief executive, is about access to documents: the General Court annulled the Commission’s refusal, finding its explanations for the messages’ unavailability insufficient, with obvious implications for how such messages are retained (
). Encryption is not at issue.
On why I consider WhatsApp a choice best avoided, see an
.
A path for every sender
If the problem is adoption, the answer cannot be to ask everyone to become an expert. What is needed is different paths for different senders, each with clearly stated limits.
- Non-technical senders. An upload link requires no installation: the sender opens a page and drops the file. An upload service over HTTPS protects the transfer; whether it also uses end-to-end encryption depends on how the service is designed. Alternatively, a 7z archive protected by a strong password: the format uses AES-256 and derives the key from the password through a process that makes guessing attempts more expensive (
), and enabling the relevant option also encrypts the file names (
). The legacy password protection of ZIP archives should be avoided: it has been vulnerable to known attacks since 1994 (
). In every case, share the password over a different channel than the file.
- First confidential contact. Some platforms let people send an encrypted message from their browser, without installing an app or creating an account; I have described one of them,
.
- People who communicate from their phones. A well-chosen end-to-end messaging app is often the most realistic compromise, as long as its limits are understood.
- Professionals who are already equipped. Encrypted email with OpenPGP or S/MIME, which I have written about
.
- Technical correspondents. Public-key file encryption, covered in the
.
A note for Italian readers and those who deal with Italian professionals: Italy’s certified email (PEC), widely used in the legal profession, is provided for by Article 48 of the Digital Administration Code for transmissions that require a receipt of sending and a receipt of delivery, and it is treated as equivalent to notification by post (
Article 48 of the Digital Administration Code on Normattiva
, in Italian). The provision concerns proof of sending and delivery, not end-to-end encryption of the content.
An example: what a secure sending path should look like
Tools matter less than the way they are offered. From the sender’s point of view, a well-designed path has these features:
- short, written instructions provided in advance, in the engagement letter, the email signature, or a dedicated page, rather than improvised on the spot;
- no installation for non-technical senders: a link that opens in the browser, including on a phone;
- the password, if one is needed, sent over a different channel from the file, such as a phone call or a message;
- an expiration date for the upload or download link, making clear that it does not affect copies already downloaded;
- a confirmation of receipt, so the sender knows the job is done and is not tempted to resend the file another way.
In practice, for the sender, it can come down to four actions: open the link in the email, choose the file on a computer or phone, send it, and see the confirmation appear. If they prepare a password-protected archive, they share the password with the recipient over a different channel, such as a phone call or a message.
Each step removes another reason to fall back on the easier, less protected route.
How to assess a tool and handle the document you receive
Trusting someone is unavoidable: most users do not check the code of what they use. Trust can, however, be calibrated to the risk. A few criteria help even non-technical users:
- who develops the tool, and for how long: a project maintained by several people and active for years may offer more grounds for trust than a brand-new one;
- published independent reviews: a security audit with an accessible report counts for more than a claim;
- code transparency: open source code, together with the provider documenting that what you install matches the published code, is a basis for trust, even though individual users cannot check it themselves;
- established cryptography: a tool built on well-known, widely used libraries deserves more trust than one that claims to have written everything from scratch.
Being listed in an app store does not replace these criteria. Apple’s guidelines, for example, ask apps to implement appropriate security measures (guideline 1.6) and describe scanning for malware, but they do not describe any check of whether cryptographic implementations are correct (
).
An encrypted file, moreover, is not harmless in itself. Encryption protects confidentiality; on its own, it neither identifies the sender nor guarantees that the content is harmless. Without the key, email anti-malware filters cannot inspect encrypted content. Confirming the submission with the sender through an independent channel helps verify the file’s origin, but it does not guarantee the content is harmless: even a genuine sender’s device can be compromised. Practical precautions are described in the
.
Finally, the document you receive. The decrypted copy no longer benefits from the original file’s protection, so you need to decide where to keep it and who can access it. It may end up in other apps, in backups, in previews; it is worth deciding in advance how to archive it and when to delete temporary copies. Among those destinations there are now also artificial intelligence tools, which deserve a section of their own.
Does it still make sense to ask for an encrypted file in the age of AI?
With AI assistants and agents that read, summarize and route documents, one may wonder whether encrypting a file has become an outdated gesture. In my view, it has not, but three aspects need to be kept apart:
- cryptographic technology does not become outdated because AI has arrived: what matters, as before, is the strength of the algorithms, the quality of the implementations and how they are kept up to date;
- the user experience, on the other hand, can feel dated: looking up a key, encrypting by hand and sending an attachment is exactly the friction described in this article;
- integration is the decisive step: encryption can become an automatic component of a workflow, rather than an operation to repeat every time.
To understand how an AI system can work with encrypted documents, we need to separate transport and storage from content processing. An agent can move or archive an encrypted file without reading it. To summarize it, search it, or extract data from it, however, in commonly used systems it must access the decrypted content. Processing can happen locally or on a remote service; in the latter case, ordinary services must be distinguished from environments designed with specific isolation guarantees. The question then becomes: where decryption happens, who authorizes it, which components can access the result, for what purpose, and with what safeguards.
When processing is remote, the decrypted content reaches a further party, and that choice should be assessed, like any other destination, in light of data protection and professional secrecy. This also applies to environments with isolation guarantees: those guarantees bear on the assessment, but do not replace it. For professionals covered by Italy’s rules on intellectual professions, moreover, Article 13(2) of Law 132/2025 requires information about the AI systems used to be given to the client in clear, simple and comprehensive language (
Article 13 of Law 132/2025 on Normattiva
, in Italian); I have written about it
. Informing the client, however, does not, by itself, make it lawful to upload a document, nor does it replace those assessments.
Among environments with isolation guarantees, some vendors have designed specific solutions. Meta states that, with Private Processing, requests to WhatsApp’s AI tools are encrypted between the device and protected processing environments that Meta and WhatsApp cannot access (
). Apple states that it designed Private Cloud Compute so it uses the personal data it receives only to fulfill the user’s request and makes it unavailable to anyone else, including Apple staff (
). Even in these environments, authorized components process the content in readable form; the protection lies in limiting who can access it. Apple acknowledges this itself: AI processing in the cloud requires the components doing the processing to access the content in the clear, so encryption cannot keep the content opaque to those components. These vendor-stated guarantees apply to those specific solutions and should not be assumed to cover every AI feature in their respective ecosystems.
Finally, AI can make encryption simpler, not unnecessary. An assistant can prepare the sending, find the recipient’s already verified key, and invoke a dedicated tool. The cryptographic operations remain in that software, and the assistant coordinates their execution; however, verifying recipients and authorizing decryption must remain explicit checks. One possible integration workflow with age is described in the
.
Conclusion
Making encryption available is not enough. If we want confidential documents to travel protected, the secure route has to be the easiest one for the people sending them, not an exam to pass. The same holds in the age of AI: in my view, document encryption is not outdated, but it needs to be integrated into new workflows instead of remaining a manual step. Security is easier to adopt when it asks little of the people communicating.
Support for strong encryption, which I share as a member of the Global Encryption Coalition (
), also means this: not only defending it in institutional settings, but making it workable in everyday communication.
I have tried to put this principle into practice: on the
page, anyone who wants to send me a confidential document can encrypt it in the browser, with nothing to install, before sending it.
New to Gemini? This capsule is best read with a Gemini client, such as Lagrange.