謎解き 鍵候補の検証｜鍵の根拠と全体への適用結果を照合する
謎解き 鍵候補の検証は、候補の出所と全入力への適用結果を逆変換まで照合する作業です。一部が読める候補でも、途中だけ規則を変えるなら根拠が不足しています。候補ごとに単位と方向と例外を固定すると、都合のよい補正を防げます。元の記号列と候補一覧を保ち、採用案と不採用案の違いを追跡します。
鍵候補の根拠と適用範囲を定める
「ID350の「謎解き 暗号」が担う全体説明は繰り返さず、謎解き 鍵候補の検証で鍵の根拠と全体への適用結果を照合する判断だけを扱う。固有作品の内容、変動する開催情報、順位付け、根拠のない断定は対象外とする。」
扱うのは鍵候補の採否であり、暗号方式全般の説明や作品内容の推測ではありません。候補は入力内の配置や公開規則から得た根拠と結び、印象だけで追加しません。出力の読みやすさだけを基準にせず、未処理部分と逆変換も確認します。安全性や秘匿性は別の評価とし、ここでは変換規則との整合だけを扱います。
全入力への適用と逆変換で確かめる
最初に原列を固定し、候補の出所と文字単位と適用方向を一行にまとめます。次に先頭だけでなく末尾まで適用し、未定義と重複と余りの位置を記します。候補が全体を処理できたら逆変換し、原列の順序と記号を照合します。最後に複数候補を同じ検査項目で比べ、補正が少ない案の根拠を精査します。
- ✓謎解き 鍵候補の検証の対象範囲
- ✓謎解き 鍵候補の検証の準備条件
- ✓謎解き 鍵候補の検証の実施順
- ✓謎解き 鍵候補の検証の例外対応
- ✓謎解き 鍵候補の検証の完了記録
公開仕様を鍵の性質の判別に使う
NIST・Cryptographic Standards and Guidelinesは、鍵を使う標準方式と独自変換を分ける入口です。RFC Editor・RFC 4648 Base Encodingsは、固定規則と鍵依存の処理を区別する資料です。RFC Editor・RFC 3986 URI Generic Syntaxは、構文記号を鍵と誤認しないために参照します。Unicode Consortium・The Unicode Standardは、鍵候補の文字表現を正確に保つ基礎です。
- NIST・Cryptographic Standards and Guidelines
- RFC Editor・RFC 4648 Base Encodings
- RFC Editor・RFC 3986 URI Generic Syntax
- Unicode Consortium・The Unicode Standard
NISTの資料に似た用語があっても、個別の候補が正しい根拠にはなりません。RFC 4648の変換規則は通常の鍵候補ではなく、対象形式が一致する場合だけ使います。RFC 3986の予約記号はURI内の役割であり、謎解き内の鍵を示すとは限りません。Unicode Standardで表現をそろえても、候補の意味や採否までは決まりません。
置換・符号化・順序変換の鍵を比べる
置換として読む案では、鍵候補が対応表の行や移動量を決めます。符号化として読む案では、候補が方式名ではなく入力形式の指定かを確かめます。順序変換として読む案では、鍵候補が要素を取り出す順番を決めます。
| 選択肢 | 確認項目 | 次に照合する項目 |
|---|---|---|
| 置換として読む | 謎解き 鍵候補の検証の対象範囲 | 謎解き 鍵候補の検証の準備条件 |
| 符号化として読む | 謎解き 鍵候補の検証の実施順 | 謎解き 鍵候補の検証の例外対応 |
| 順序変換として読む | 謎解き 鍵候補の検証の完了記録 | 謎解き 鍵候補の検証について、鍵の根拠と全体への適用結果を照合するための実務判断だけに限定する |
置換案は全記号の対応を検査し、未登録要素を推測で補いません。符号化案は文字種と単位長を仕様へ照合し、秘密語を不要に持ち込みません。順序変換案は要素数と重複を比べ、並べ替え前の位置へ戻せるか確認します。どの案でも候補の出所、適用範囲、逆変換の三点がそろってから採用します。
候補が競合する場面を切り分ける
候補台帳には候補名・出所・入力単位・方向・適用範囲・逆変換結果を記します。試験対象には先頭と末尾と反復部分を含め、都合のよい区間だけを選びません。候補を作る担当と検査する担当を分ける場合は、採用理由を先に共有しません。
先頭の区間だけ成立する場合
例えば、候補が先頭の数単位だけ処理できても、残りが未定義なら確定できません。規則を変えず末尾まで適用し、最初に破綻する位置と要素を記録します。入力ミスを疑う場合も原列を直さず、候補側の単位設定と分けて検査します。
二つの候補で読める断片が出る場合
例えば、異なる二候補で短い断片が読めても、偶然の一致を除外できません。全体の処理率だけで競わせず、候補の出所と例外数と逆変換を照合します。差を説明できない場合は両方を保留し、片方を推測で除外しません。
見た目が同じ鍵で結果が違う場合
結合文字や幅の違いにより、見た目が近い鍵でも文字情報が異なることがあります。原表記と正規化後の表記を別欄に置き、使用した形を明示します。表記を直した後は全入力を再処理し、以前の途中結果を混ぜません。
採否理由と再検査結果を記録する
候補を退ける際は読めないという感想ではなく、破綻位置と規則違反を残します。例外処理が必要なら適用条件を明記し、場当たり的な補正と区別します。修正候補は新しい行として追加し、元候補の記録を上書きしません。全入力の処理と逆変換を再現でき、採否の根拠が説明できれば完了です。
意味のある断片が出た候補を優先できますか？
断片の読みやすさは参考になりますが、単独では採用理由になりません。残りの入力へ同じ規則が続き、逆変換で原列へ戻るかを確かめます。候補の出所が入力内の配置や指示と結び付くことも必要です。
入力外で思いついた候補も試せますか？
試すことはできますが、入力内の根拠を持つ候補とは分けて管理します。外部知識だけに依存する案は、適用結果が良くても確定を急ぎません。採用するなら、なぜその候補を選べるかを他者が追える形で残します。
複数候補が最後まで残ったらどうしますか？
根拠と例外と逆変換を並べ、差が生じる試験入力を探します。判別できない場合は候補を統合せず、未確定の選択肢として保存します。追加情報を得た後に同じ検査表へ戻り、全体を再実行します。
鍵候補は読める断片より、出所と全体適用と逆変換で評価します。置換、符号化、順序変換を分けると、鍵が担う役割を特定できます。破綻位置と例外を残せば、候補を修正する範囲が明確になります。採否理由を台帳へ記し、別の人が再検査できる状態で完了します。