「modナンバーのルールと応用」の編集履歴（バックアップ）一覧はこちら
「modナンバーのルールと応用」(2009/05/08 (金) 19:55:46) の最新版変更点
追加された行は緑色になります。
削除された行は赤色になります。
このページの情報を利用することで、ハッシュ衝突で実質400個も使えなかったMODナンバーを３０倍以上に増やすことができます。
**NxxxXXXX_Xxx
情報を応用して問題の少ない文字列に変更していきましょう。
レポート１
_の文字はカテゴリ識別ではなく、アイテム番号の一部です
従来の８桁_３桁というナンバリングは単に可読性を求めた場合の物で、実際は９桁３桁でも問題なく処理されます。
レポート２
例としてN006KASUXE00とN108KASU_E00から得られるハッシュ値が共に0428B27Eである等、単に一部の文字列が違えば問題がないという訳ではなく、一文字変更した程度ではあらゆる文字列で衝突が発生してしまいます。
レポート３
10の倍数はぶつかりやすいという言い伝えですが、正確には10の倍数に限った事象ではありません。
まずNXXXは３桁でなく２桁+αとして処理されるため、XXXで３桁分の集合という訳にはいかない仕様になってしまっています。
巡回冗長検査で、ハッシュ値を求める多項式として0x1aという値を採用し、x<<4+x<<3+x<<1を加算して設計上問題のない範囲への集合を狙った様ですが、そもそもそこに問題があったということになります。
&bold(){つまり、暗号化に使える元の数を制限してあるために、そもそも出来る暗号のパターンが限られているということです。}
結果としては_を他の文字に変えると、_の領域に一切かぶらない文字が多数見つかりました。
ただし_以外の文字同士の間にも衝突集合が必ず存在し、絶対に衝突が起きない文字はやはり存在しません。
データベースの機能を活用して衝突する集合を回避しながら運用する事で、使用可能なmodナンバーを大きく拡大する事は簡単です。
このページの情報を利用することで、ハッシュ衝突で実質400個も使えなかったMODナンバーを３０倍以上に増やすことができます。
**NxxxXXXX_Xxx
情報を応用して問題の少ない文字列に変更していきましょう。
レポート１
_の文字はカテゴリ識別ではなく、アイテム番号の一部です
従来の８桁_３桁というナンバリングは単に可読性を求めた場合の物で、実際は９桁３桁でも問題なく処理されます。
レポート２
例としてN006KASUXE00とN108KASU_E00から得られるハッシュ値が共に0428B27Eである等、単に一部の文字列が違えば問題がないという訳ではなく、一文字変更した程度ではあらゆる文字列で衝突が発生してしまいます。
レポート３
10の倍数はぶつかりやすいという言い伝えですが、正確には10の倍数に限った事象ではありません。
まずNXXXは３桁でなく２桁+αとして処理されるため、XXXで３桁分の集合という訳にはいかない仕様になってしまっています。
巡回冗長検査で、ハッシュ値を求める多項式として0x1aという値を採用し、x<<4+x<<3+x<<1を加算して設計上問題のない範囲への集合を狙った様ですが、そもそもそこに問題があったということになります。
&bold(){つまり、暗号化に使える元の数を制限してあるために、そもそも出来る暗号のパターンが限られているということです。}
結果としては_を他の文字に変えると_の領域に一切かぶらない文字は多数見つかりました。ただし_以外の文字同士の間にも衝突集合が必ず存在し、絶対に衝突が起きないという文字はやはり存在しません。
&bold(){データベースの機能を活用して衝突する集合を回避しながら運用する事で、使用可能なmodナンバーを大きく拡大する事は簡単です。}
