NearSeal

2026-09-05

You encrypted the file. How do you send the passphrase without undoing it?

Every guide to sending a sensitive file stops in the same place. Encrypt it first, they say — and then the sentence just ends. The other half of the job, getting the passphrase into the hands of the one person who needs it without handing it to everyone else who might be reading, is left as an exercise for the reader. Most people solve that exercise by typing the passphrase into a second email. This post is about why that particular solution has been dismantled, in public, over five years, by a whole country's worth of institutions — and what the people dismantling it actually recommend instead.

The ritual that got a name

Japan is the one place that named the habit, studied it, and then set about ending it. The name is PPAP — a tongue-in-cheek acronym, riffing on the 2016 novelty song, for "send a password-protected ZIP, then send the password." For years it was the default courtesy of Japanese business email, and it is still being unwound one large organization at a time. On 8 June 2026 ITmedia reported that MUFG Bank is abolishing the practice in principle, phased in from 18 July 2026, and switching to a download URL in the body of the email with the password delivered separately. The bank's stated reason is the interesting part, and we will come back to it: because the file is encrypted, malware checking at the moment the mail arrives is difficult.

If you have never heard of any of this, it can read as an argument against encrypting files you send. It is the opposite. Read what the officials actually said.

What the Japanese government actually abolished — and what it did not

The turning point was a routine ministerial press conference. In the official Cabinet Office transcript of 24 November 2020, then digital reform minister Takuya Hirai confirms that the Cabinet Office and the Cabinet Secretariat would, two days later, stop the method of automatically sending the password down the same route as the encrypted ZIP. His verdict on it: 「セキュリティ対策の観点からも、受け取る側の利便性の観点からも、適切なものではない」 — not appropriate, from the point of view of security measures nor from the point of view of the recipient's convenience.

Then comes the sentence almost every summary of this story leaves out. Asked what should happen instead, he describes it as putting a password on the file 「とともに、全く別の経路でパスワードを 知らせる」 — and along with that, telling the password by a completely different route — offering, as a concrete example, 「電話で教える」, telling it over the phone. As ITmedia reported at the time, external file sending would move to storage services, with the password arranged separately.

That is not a government telling people to stop protecting files. It is a government saying the protection was never the problem: the second email was. And a few days earlier the point had been made from another direction. On 19 November 2020, JIPDEC — the body that runs Japan's Privacy Mark certification, which many companies believed was the reason they had to do PPAP in the first place — stated flatly that attaching a password-encrypted file containing personal information and sending the password in a separate email was 「以前から推奨していない」, something it had never recommended.

Why a second email is not a second channel

There is one test, and it is short. Would a single compromise reveal both halves? If yes, you did not use two channels; you used one channel twice.

Run the test honestly and the second email fails it in almost every direction. If someone has access to the recipient's mailbox — the entire premise of business email compromise — they have both messages, sitting a few rows apart, helpfully adjacent. If the mail was misdirected because autocomplete filled in the wrong Kim or the wrong Sarah, autocomplete will make the same mistake thirty seconds later with the password, and both land in the same stranger's inbox. If the thread is later forwarded to a wider group, or the recipient leaves and their mailbox is handed to a successor, or the mailbox is backed up somewhere, the two messages travel together as a matched set. The passphrase is only doing work if it lives somewhere the file does not.

The attackers noticed first

Here is the uncomfortable part, and it is the reason large organizations now delete these attachments rather than merely discourage them. Criminals adopted the identical ritual, because it works — for them.

In a spam campaign Trend Micro documented on 6 April 2019, invoice-themed mail arrived carrying a password-protected ZIP with a four-digit password written in the message body. The archive held a trojan downloader that pulled down EMOTET. The password in the body is not sloppiness; it is the whole design. A mail gateway cannot scan what it cannot open, so the encrypted archive sails through inspection and the human, helpfully, supplies the key.

That is exactly the reasoning IIJ published when it stopped accepting these attachments altogether: from 26 January 2022, password-protected .zip files sent to IIJ are deleted and only the message body is delivered. The company noted that the U.S. Cybersecurity and Infrastructure Security Agency has recommended blocking such attachments because they are often able to slip past virus scans, and that the method can be misused to spread malware. MUFG's 2026 reasoning is the same sentence in a different suit.

The honest conclusion for anyone who encrypts files is not "so don't." It is that encrypting an attachment transfers a cost to the person receiving it: you have switched off their scanner for that file. That is fine between two people who arranged the exchange in advance. It is not fine as a surprise arriving from an address someone half-recognizes, and it is the reason encrypted mail attachments are increasingly a worse delivery mechanism than a link — regardless of how good the encryption is.

Is it really a second channel? One question decides it Would one compromise reveal both the file and the passphrase? If yes, that is one channel used twice — not two channels Not a separate channel Actually separate — A second email to the same address — A reply inside the same thread — The chat window that carried the file — A note left in the same shared folder — A hint in the filename or the subject — A call to a number you already had — A different app the file never touched — Agreed in person, before anything was sent — A password manager's share feature — Spoken aloud at a meeting you both attend SMS sits in between: it survives a compromised mailbox, not a stolen or SIM-swapped phone And no channel saves a passphrase that is guessable from the file it opens
Two channels means two things that fail independently. A second email to the same mailbox fails at exactly the same moment as the first one.

Picking a passphrase you will have to say out loud

The current baseline is NIST Special Publication 800-63B-4, published 26 August 2025, and its advice is blunter than most people expect. Verifiers "SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length." They "SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types)." They "SHOULD accept all printing ASCII characters and the space character" and "SHOULD permit a maximum password length of at least 64 characters." And they should compare the choice against a blocklist of known common, expected or compromised passwords.

Translated into the situation you are actually in: length beats punctuation. Several unrelated words with spaces between them will outlast a short string with a dollar sign wedged into it, and it has the practical virtue of being sayable on a phone call without spelling every character. Two more rules that come from the situation rather than the standard. Do not derive the passphrase from the file or the transaction — anything shaped like "Invoice-Kim-2026!" is guessable by exactly the person who intercepted the email it was attached to. And do not reuse the same passphrase for every file you send to that person over a year; one leak then unlocks the archive.

Your encrypted attachment may not even arrive

This is the practical failure that surprises people. The recipient's mail system may simply refuse it. IIJ deletes password-protected ZIP attachments outright. MUFG is moving to links. And the direction of travel is measurable: a Digital Arts survey conducted in December 2024, reported by IT Leaders on 30 January 2025, found the share of email carrying ZIP attachments had halved over five years, from 25% to 12%, with 56% of the remaining ZIPs password-protected. The habit is fading, but slowly — JIPDEC's Enterprise IT Utilization Trend Survey 2024 found 27.1% of surveyed companies still used PPAP as their only method of sending files as of January 2024, a figure cited by ASCII.jp in its coverage of the Financial Services Agency's May 2025 industry meetings, where the regulator pressed financial institutions to stop the practice. (We have not been able to read that FSA document directly, so treat the meeting detail as reporting rather than as a quoted regulation.)

What that means for you is simply: ask before you send. If their gateway strips encrypted attachments, the working pattern is the one MUFG is adopting — put the encrypted file somewhere they can fetch it, and send the passphrase down a genuinely different channel. The encryption is what makes the storage location unimportant.

A five-step version you can actually follow

One, agree the channel first, in a sentence: "I'll email the encrypted file and call you with the passphrase." Doing this before you send also warns them the attachment is coming, which is the courtesy that keeps it from looking like the EMOTET campaign above. Two, encrypt the file, and write the passphrase into your password manager at the moment you create it — not afterwards, when you think you will remember. Three, send the file. Four, deliver the passphrase by the other channel, and never paste it into the thread "so it's easy to find." Five, keep your own plaintext copy until they confirm they have opened it, then clean up. That last step is not paranoia; it is the only recovery mechanism that exists, and the next section explains why.

What none of this fixes

Five limits, stated plainly. First, encryption protects the file in transit and at rest; it does nothing about what the recipient does after they open it. If they decrypt it onto a synced desktop and forward it onward in the clear, your careful channel separation ends there. Second, it does not make their mailbox safe, and it does not verify who they are: if the address you are replying to was spoofed or the thread was hijacked, you will encrypt the file beautifully and hand the passphrase to the attacker on the phone number in their signature. Confirm the channel against contact details you already had, not the ones in the email. Third, it blinds the recipient's malware scanner for that file, which is a real cost to them and the reason an unexpected encrypted attachment is bad manners as well as bad security. Fourth, metadata still leaks: the filename, the size, the subject line and the fact that you and this person exchanged something today are all visible whatever is inside. Fifth, and most important, there is no recovery. A passphrase-encrypted file has no reset link, no support ticket, no backdoor for the sender or for us. If your recipient loses the passphrase, nobody can open that file — which is precisely why you keep the original until they confirm, and why the passphrase belongs in a password manager on both ends rather than in someone's memory.

Where NearSeal fits

NearSeal does the first half of this job, and it is deliberately unable to do the second. The encryption runs entirely in your browser: the file and the passphrase never leave your device, there is no account and no upload, and you can watch the network tab confirm that nothing is transmitted. There is no "send to recipient" button, no link generation, no passphrase relay — not as a missing feature, but because a passphrase channel operated by the same service that holds the file would collapse the two channels back into one, which is the entire mistake this post is about. The default format is AES-256-GCM with the key derived from your passphrase by PBKDF2-SHA256 at 220 iterations, and the container header is bound into the authentication tag, so a tampered file fails loudly at decrypt time rather than quietly handing over altered data. If your recipient would rather not depend on any website, there is the opt-in age-encryption.org format: age files use scrypt and ChaCha20-Poly1305, and they open in the official age CLI, in rage, and in any other age-compatible tool, so the person at the other end never has to visit this site at all. Decryption recognizes either format by its bytes, not its filename. The passphrase is still yours to carry to the other person — by phone, in person, or through anything else that fails independently of the file.