How to audit zip encryption for security & compliance
- Step 1Stage the archive locally — Pull the ZIP from your evidence store, vendor inbox, or pipeline artifact to the analyst workstation. The detector reads from disk via the File API — nothing transits a network at any point.
- Step 2Open the detector — Go to /archive-tools/encrypted-archive-detector. For larger evidence ZIPs, use Pro (500 MB) or Pro+Media (2 GB) so you don't have to split the file first.
- Step 3Run the per-entry scan — Drop the ZIP and click Process. The tool reads each central-directory entry's encrypted flag and AES extra field — no decryption, no password. A mixed result means the archive isn't uniformly protected.
- Step 4Record the verdict — Download
<name>-encryption.jsonand attach it to the case/ticket. TheencryptionSummaryis a concise, dated statement of posture; theentriesarray names any weak file specifically. - Step 5Remediate weak archives — If any entry is ZipCrypto, re-encrypt the whole archive with AES-256 via encrypted-zip-creator before it leaves the boundary, then re-run the detector to confirm an all-AES-256 result.
- Step 6Pair with a tamper-evident manifest — For chain-of-custody, run checksum-generator to produce a SHA-256 manifest of the entries alongside the encryption report, so you have both 'how it's protected' and 'what it contained.'
Compliance verdict by detected method
How to read each detector result against a typical data-handling policy. Verdicts come straight from plaintext ZIP metadata — no decryption involved.
| Detected method | Compliance posture | Recommended action |
|---|---|---|
| AES-256 | Acceptable for sensitive data | Confirm password strength is policy-compliant; pass |
| AES-192 / AES-128 | Strong; usually acceptable | Pass unless policy mandates AES-256 specifically |
| ZipCrypto (legacy) | Fail — effectively unprotected | Re-encrypt with AES-256 before the archive leaves the boundary |
| Unencrypted entry in a 'secure' ZIP | Fail — data leak | Re-package with all entries encrypted |
| Mixed (AES + ZipCrypto) | Fail — weakest entry governs | Re-encrypt the entire archive uniformly |
Why no-upload matters for regulated workflows
The detector's architecture keeps the data boundary where it already is — the key reason it fits compliance use.
| Concern | How the detector handles it |
|---|---|
| Evidence/PII leaving the boundary | It doesn't — the file is read in-browser via the File API; no network request carries the bytes |
| Install permissions on hardened laptops | None needed — it's a web page, no admin rights, no agent |
| Air-gapped review | Works offline once the page is loaded; pure client-side ZIP parsing |
| Audit trail | Downloadable JSON report you attach to the case as a dated record |
| Holding third-party passwords | Not required — detection reads metadata only, never decrypts |
Cookbook
Audit scenarios analysts actually face. The JSON shown is the real downloaded report.
Vendor export that quietly used ZipCrypto
A vendor sends a 'password-protected' export of customer records. The detector reveals it's ZipCrypto — a failing posture for PII. You bounce it back or re-encrypt before ingesting.
Input: vendor-customers.zip
Report (vendor-customers-encryption.json):
{
"totalEntries": 4,
"encryptionSummary": {
"AES-256": 0, "AES-192": 0, "AES-128": 0,
"ZipCrypto (legacy)": 4, "Unencrypted": 0
}
}
Verdict: FAIL — request an AES-256 re-export.Outbound evidence package — confirm AES-256 before sending
Before sending an evidence ZIP to outside counsel, confirm every entry is AES-256. The all-AES-256 summary becomes the dated record attached to the case.
Input: case-2026-0142.zip
Report:
{
"totalEntries": 18,
"encryptionSummary": {
"AES-256": 18, "AES-192": 0, "AES-128": 0,
"ZipCrypto (legacy)": 0, "Unencrypted": 0
}
}
Verdict: PASS — attach report to chain-of-custody log.Half-re-encrypted archive caught in review
An analyst started re-encrypting an old ZipCrypto archive to AES-256 but the job was interrupted. The mixed summary catches it — the archive is only as strong as its weakest entry.
Report:
{
"totalEntries": 20,
"encryptionSummary": {
"AES-256": 17, "AES-192": 0, "AES-128": 0,
"ZipCrypto (legacy)": 3, "Unencrypted": 0
}
}
Verdict: FAIL — 3 ZipCrypto entries remain. Re-encrypt all 20.Plaintext file hiding in a 'secure' archive
A 'secure' deliverable has one unencrypted entry — a leak. The per-entry array names it so remediation is targeted.
Report entries (excerpt):
[
{ "name": "summary.pdf", "encrypted": true, "method": "AES-256" },
{ "name": "raw-pii.csv", "encrypted": false, "method": "None" }
]
Summary: AES-256 = 9, Unencrypted = 1
Verdict: FAIL — raw-pii.csv is in the clear.Detector + checksum manifest for chain-of-custody
Pair the encryption verdict with a content manifest so the case record states both how the archive is protected and what it held at review time.
Step 1: encrypted-archive-detector → case-encryption.json
(AES-256 = 18, all entries protected)
Step 2: checksum-generator (SHA-256) → case-sha256.csv
name,size,sha256
exhibit-01.pdf,204813,9f2c...e1
...
Attach both to the chain-of-custody log.Edge cases and what actually happens
Archive is ZipCrypto despite a 'password protected' label
FailA ZIP can be password protected with ZipCrypto, which is broken. The detector reports method: ZipCrypto regardless of how strong the password is, because the scheme itself is the weakness. For any sensitive-data workflow, treat ZipCrypto as a failing posture and re-encrypt with AES-256.
Unencrypted file inside a 'secure' archive
FailEncryption is per-entry, so a single plaintext file in an otherwise-AES archive is a data leak. The detector marks it encrypted: false, method: None and counts it under Unencrypted. Review the per-entry array, not just the headline that the archive 'has encryption.'
Mixed AES and ZipCrypto in one archive
FailAn archive is only as strong as its weakest entry. A mix of AES-256 and ZipCrypto entries (often an interrupted re-encryption) fails review — re-encrypt the entire archive uniformly and re-run the detector to confirm a clean summary.
Input is not a ZIP (7z / RAR / TAR.GZ)
Not a valid ZIP archiveThe detector is ZIP-only. A 7z's 7zAES or a RAR's encryption isn't classifiable here — the tool throws Not a valid ZIP archive. Confirm the container with auto-format-detector; for non-ZIP formats, use the native tool or your endpoint scanner to assess encryption.
Evidence file exceeds the tier size cap
Tier limit exceededFree caps at 50 MB. Large evidence ZIPs need Pro (500 MB) or Pro+Media/Developer (2 GB). The detector reads the whole file into memory, so even within the cap a multi-GB archive is memory-heavy; split or stage it on a workstation with sufficient RAM.
AES-256 confirmed but password is weak
PartialThe detector verifies the algorithm, not the password. An AES-256 archive with a weak password is still brute-forceable. Confirm password strength against policy separately; the detector's PASS means 'strong scheme,' not 'strong secret.'
Air-gapped or no-network review environment
SupportedOnce the page loads, detection runs entirely client-side with no network calls, so it works in air-gapped or network-restricted environments. This is also why it's safe for sensitive evidence — there is no upload path to disable.
Need a tamper-evident record, not just a verdict
PreservedThe encryption report states posture but not content. Pair it with checksum-generator for a SHA-256 manifest of the entries, giving the case both 'how protected' and 'what it contained' at review time.
Frequently asked questions
Is using a browser tool acceptable in a regulated environment?
Because nothing transits a network — the ZIP is read in the browser and never uploaded — the regulated boundary doesn't move when you run the detector. It's equivalent to running a local CLI. Confirm with your compliance team, but most treat local browser processing the same as local tooling.
Why is ZipCrypto a compliance failure?
ZipCrypto has a published known-plaintext attack: with ~12 known plaintext bytes (often guessable from common file headers), the password is recoverable in seconds. A sensitive archive 'secured' with ZipCrypto is effectively unprotected, which fails the intent of virtually every encryption-at-rest/in-transit control.
Do I need the password to vet a third-party archive?
No. Encryption type is plaintext metadata, so the detector classifies a vendor's ZIP without holding their password. That makes it ideal for inbound vetting where you can't (and shouldn't) be given the secret.
Can it audit 7z or RAR archives too?
No — it's ZIP-only and throws Not a valid ZIP archive. on other containers. 7z and RAR use different encryption layouts (e.g. 7zAES). For those, use the native tool or your endpoint controls. Confirm the format first with /archive-tools/auto-format-detector.
Does an AES-256 result mean the archive is compliant?
It means the scheme is strong. The detector doesn't evaluate password strength or key management — an AES-256 ZIP with a weak password is still vulnerable to brute force. Treat a PASS as 'strong algorithm confirmed,' and verify the password meets policy separately.
How do I produce an audit record?
Download the <name>-encryption.json report and attach it to the ticket or case. The encryptionSummary is a concise, dated statement of posture and the entries array names any weak file. For content integrity, pair it with a SHA-256 manifest from /archive-tools/checksum-generator.
What about chain-of-custody?
Run the detector and /archive-tools/checksum-generator on the same file at intake and again before release. The encryption report shows how it's protected; the checksum manifest proves the contents are unchanged. Both are downloadable JSON/CSV you can log.
Can multiple analysts use it at once?
Yes — each browser tab is an independent, stateless instance, so there's no shared queue or contention. Free-tier limits apply per session; Pro and above raise the size and entry caps for larger evidence files.
Will it work on a hardened, no-admin laptop?
Yes. There's nothing to install — it's a web page that runs in the browser. That's a key advantage over CLI tools like p7zip, which need install rights you may not have on a managed device.
How large an archive can I audit?
Free: 50 MB and up to 500 entries. Pro: 500 MB / 50,000 entries. Pro+Media and Developer: 2 GB / 500,000 entries. Enterprise: unlimited. Oversized files are blocked before processing with a tier-limit error; use /archive-tools/archive-splitter to break up an over-cap archive if needed.
What if the archive is corrupt?
The detector walks the central directory and stops at the first bad record, so a damaged archive may report fewer entries than expected. Treat an unexpectedly short report as a flag — run /archive-tools/corrupted-zip-repair to assess the damage before drawing audit conclusions.
Can this replace our endpoint DLP scanner?
No — it's a focused encryption-posture check, not a full DLP/content-inspection platform. Use it as a fast, private gate to catch weak-encryption archives at review time; keep your DLP and endpoint controls for content classification and policy enforcement.
Privacy first
Every JAD Archive tool runs entirely in your browser using fflate, @zip.js/zip.js, and the libarchive WASM bridge. Your archives never leave your device — verified by zero outbound network requests during processing.