File handoff · Tech
Check what is visible before the password
A four-case test separates encrypted contents, hidden filenames and a usable handoff.
- The password may protect only the contentsOur AES-encrypted ZIP exposed both internal filenames before a password was supplied.
- 7z header encryption changed the listingWith -mhe=on, our 7z archive requested a password before revealing the file list. With -mhe=off, the names remained visible.
- The attachment still has an outside labelHeader encryption did not conceal the outer archive name. A descriptive name could disclose the project before anyone opened it.
A filename can disclose a client, a negotiation or a fee discussion without revealing a single sentence inside the document. That matters when the person preparing an attachment sees a password prompt and assumes the whole package has become unreadable.
We tested that assumption with two harmless files and four archives. The question was deliberately narrow: could a fresh 7-Zip process list the internal names without receiving the password? Two of our three encrypted archives could. The setting that changed the outcome was encryption of the 7z header, where file information is held.
This was an executed local test using the x64 console tool from the official 7-Zip 26.03 Extra package, released on 3 September 2026. It did not attempt password cracking, assess algorithm strength or test every archive application. Its useful result is a distinction you can verify before sending a real package.
The file list survives two kinds of encryption
Our files were named client-alpha-budget.txt and internal-fees.csv. They contained explicitly synthetic text and fictional numbers. We created an unencrypted ZIP as a control, a ZIP with AES-256, an encrypted 7z with header encryption off, and an encrypted 7z with header encryption on.
Each archive went through a new passwordless listing process, a test with an incorrect password, a test with the correct password, and extraction of the text file for an exact comparison with its original contents. The plaintext control required no password; supplying one did not turn it into an encrypted archive.
Four archives made from the same two files
| Archive setting | Names without password | Wrong-password test |
|---|---|---|
| ZIP · no encryption | Both visible | Passed · password irrelevant |
| ZIP · AES-256 | Both visible | Rejected |
| 7z · headers open | Both visible | Rejected |
| 7z · headers encrypted | Neither listed | Rejected |
The encrypted ZIP result is consistent with WinZip’s AE-1/AE-2 specification: its encryption covers compressed file contents, while the surrounding ZIP structure is retained. Choosing AES does not imply that every field associated with the file becomes concealed.
For 7z, we explicitly set -mhe=off and -mhe=on, rather than relying on an application’s defaults. The 7-Zip 26.03 source code maps the header-encryption property to its encrypted-header setting. Our two 7z cases show why the format name and the existence of a password are insufficient descriptions of the package.
With encrypted headers, the listing stopped at a password request and printed neither internal filename. The unattended process then ended because no input was provided. That termination is different from our separate wrong-password test, which actively supplied an incorrect value. We did not treat an interrupted prompt as evidence of a failed password attempt.
The outer name survives the stronger setting
Next, we copied the successful header-encrypted archive under the name Project-Alpha-fees.7z. Its contents were unchanged. A passwordless listing still did not reveal either internal name, but the outer filename now advertised the project and the subject of the package.
This counterexample limits the obvious advice to “turn on filename encryption.” That setting addressed the internal list in our test. It did not rename the attachment, hide its total size or remove clues placed in a message subject or accompanying text. The protection has a defined scope.
Neutral naming is useful when the filename itself is sensitive. It does not make a transfer anonymous, revoke copies already extracted or compensate for an unsafe receiving device. Nor does it answer the algorithm-lifetime question discussed in our explanation of post-quantum cryptography. Here, the exposed names were available without any cryptographic attack.
Reproduce the distinction with harmless files
Use an empty test directory containing only the two files named above, filled with obvious demonstration text. The following PowerShell commands reproduce the two encrypted settings that matter most. They assume 7za is available on your command path; our test used the portable x64 executable from the Extra package.
The password below is public demonstration data. Use it only for this harmless example. For a real package, choose a private password and enter it through the tool’s password prompt instead of copying it into command history.
$demo = 'PUBLIC-DEMO-ONLY-' +
'7zip-2026'
$files = @(
'client-alpha-budget.txt',
'internal-fees.csv'
)
$zip = @(
'a', 'content-aes.zip', '-tzip',
'-mem=AES256', "-p$demo"
)
$seven = @(
'a', 'names-hidden.7z', '-t7z',
'-mhe=on', "-p$demo"
)
7za @zip @files
7za @seven @filesInspect each archive in a new process without passing -p:
7za l -slt content-aes.zip
7za l -slt names-hidden.7zFor the first command, inspect the output for both filenames. For the second, inspect what appears before entering any password; cancel the prompt after recording the result. If the names have already appeared, the package has failed the filename-concealment requirement regardless of whether opening a document later requests a password.
To match the other two cases, create a new ZIP without encryption and a new encrypted 7z with -mhe=off. Keep these separate from the existing archives so that an update to an old package does not obscure what was created. All four cases in our test used the same two source files.
A concealed index still has to reach a usable recipient
Our correct-password tests succeeded, and extracting client-alpha-budget.txt reproduced the original text exactly in every case. That is evidence for recovery with the tested tool. It does not establish that an employee’s locked-down laptop, a phone’s default file viewer or a recipient’s upload portal accepts encrypted 7z.
Before the actual handoff, send a harmless sample through the intended route and have the recipient open it with the software they will use. Confirm both requirements: the package conceals the fields that matter before authentication, and the authorized recipient can recover the intended files. If their software cannot do both, the sharing method needs to change.
This is especially concrete for a server-log investigation. A folder or filename may identify the site or incident being discussed even when log contents are encrypted. Decide whether that identifying context may travel outside the protected content before choosing the archive settings.
The same recovery check also has a different time horizon from keeping an offline SSD backup usable. A package that opens today has passed a present handoff test. Long-term storage still depends on retaining the password, compatible software and readable media.
The final check is therefore an observation from the receiving side: what can be learned before supplying the password, and what can be recovered after supplying it? Our four archives produced different answers to the first question even though all three encrypted versions rejected the incorrect password. That is why a password prompt alone is too little evidence to approve the package.
Primary format sources and test method
Checked 13 September 2026. We used 7-Zip (a) 26.03 x64 on Windows. Each listing ran in a fresh process with no password argument and empty standard input. The encrypted-header listing requested a password, printed no internal names and ended with exit code 255 after input ended. Separate incorrect-password tests returned exit code 2 for all three encrypted archives; correct-password tests returned 0. The unencrypted control returned 0 regardless of the supplied password.
The extraction comparison covered the text file, not an independent byte comparison of both files. The archive test operation covered each complete archive. Saved creation, listing, test and extraction outputs support the results. Copying the encrypted-header archive to Project-Alpha-fees.7z supplied the outer-name counterexample. This was not a brute-force, forensic, malware, cloud-privacy or cross-application compatibility audit.
