長い ZIP パスワード：正解入り辞書でも見つからない理由
指定の John PKZIP 1.9.0-jumbo-1 は 31 文字を検出しましたが、正しい 32・51・52・127 文字は検出しませんでした。全原本は別経路で完全復号でき、失敗はツール側の制限でも起こるとわかります。
正解を辞書へ直接入れる
同一の架空本文を持つ従来方式 ZipCrypto の ZIP を 5 個自作し、31・32・51・52・127 文字の ASCII 公開値を設定。顧客ファイル、顧客パスワード、私的なヒントは使いません。
各辞書は誤答 1 個と正解だけ。以前の記録が影響しないよう各テストに独立したセッションと空の potfile を用意しました。John 1.9.0-jumbo-1 cygwin 64-bit x86_64 AVX2 AC OMP を使用し、Python でも元ファイルを全読込して本文と CRC を確認しました。
結果をどこまで一般化できるか
ローカルの形式情報は、このビルドの ASCII 上限を 31 文字と報告しました。Openwall にも同種の制限の資料があります。すべての John 版、ZIP AES、ZIP 規格全体の上限という意味ではありません。
制限は復旧経路のものです。127 文字のサンプルも既知値で全内容を読める有効な暗号化アーカイブなので、単一モジュールの不検出を根拠に無効とはいえません。
| パスワード長 | 正しい候補を投入 | John PKZIP で検出 | 元ファイルの完全検証 |
|---|---|---|---|
| 31 | はい | はい | 合格 |
| 32 | はい | いいえ | 合格 |
| 51 | はい | いいえ | 合格 |
| 52 | はい | いいえ | 合格 |
| 127 | はい | いいえ | 合格 |
ヘッダー一致だけでは成功と呼べない
ZipCrypto の短い検査フィールドは候補絞り込みに使えますが、偶然一致もあり得ます。独立した長パスワードフィルターは全 5 件の正解を見つけました。それでも元メンバー全体と本文・CRC の確認を必須とします。
データ記述子フラグの有無で検査バイトの出所が変わるため、ZIP フラグを正しく扱う必要があります。自作コードを正しいと仮定するより、既知値での対照が重要です。
見つからない場合の確認順序
形式と暗号化（ZipCrypto と ZIP AES は別）、対応長と文字コードを確認。同じ長さの非私的サンプルを作り、正解を小辞書へ入れ、空の結果保存先で試します。検出後は原文全体で検証し、対照が失敗すれば大辞書を評価する前に設定を調べます。
ASCII 対照は Unicode 対応を証明しません。WinRAR や 7-Zip の汎用的な上限測定、ZIP AES の速度評価、任意の長パスワードの復旧保証ではなく、特定の陰性テストが無効になる例です。
公開対照をダウンロード
正確なテストパスワードと SHA-256 は JSON に掲載。公開値を本物の秘密ファイルに再利用しないでください。5 つの原本と候補フィルター実装を確認できます。
コードは候補のふるい分け専用で、完全復号の検証に代わるものではありません。成功対照と指定旧モジュールの想定不検出を示すもので、製品ランキングではありません。
参考資料と追加確認
適用範囲と編集上の独立性
当社は復旧サービスも提供しています。実験には自作の架空ファイルだけを使用し、顧客ファイルは使用しません。結果は記載の環境・日付・サンプルに限られ、全体の成功率、検索順位、復旧保証を示しません。