アカウント名:
パスワード:
チェックデジットをアルファベットにしたらいいだけではないの?
間違えても通ってしまうのが問題なんだからアルファベットにしたところで意味はないだろうマイナンバーのSHAを入力してもらえばいい入力ミスしても通ることはまずない
ちゃんとリンク先を読め、で終わる話なんですが説明しとくと、個人用マイナンバーと法人用マイナンバーでは全然別のチェックデジット付加方法を採用してますが、
個人用マイナンバーは、mod 11 なので、チェックデジットに11種類の文字が必要ですが、それを数字で表現するために、余り0も余り10もチェックデジットを割り当ててます。その結果、チェックデジットが0の場合は、「余り0が余り10になったり、余り10が余り0になるような誤りは、チェックデジットが0のまま変わらない」から誤り検出できないので、誤り検出率が落ちるという問題があります。
法人用マ
不思議なんですが、そういう問題があることが明らかなのになんでチェックサムの計算方式ではmod 9やmod 11が主流なんでしょうか。かつてのrand関数みたいに特に理由もなく昔から使われているものが使われているだけなんでしょうか。
mod 11 には、全然問題はありません。mod 11 では11種類のチェックデジットが発生するので、数字1桁で表現できない、というデメリットがあるだけ。それを、余り10も余り0もチェックデジットを0にする、という個人用マイナンバーのアルゴリズムが腐ってるんです。「桁の入れ替わりを検出するため、個々の桁に固有の定数をかける」場合、その定数とモジュロが互いに素である事が重要です。例えば、mod 10 で、ある桁の数値に2をかけると、その桁では0(×2=0)と5(×2=10)のチェックデジットが一致することになってしまいます。11は素数なので、「互いに素となるような数を多く作り出せる」という点でメリットがあります。
法人用マイナンバーの mod 9 は、まー論外ですね。そんな方法を使ってるとこはどこにもありません。主流でもなんでもないです。
JANコードと法人マイナンバーのアルゴリズムはよく似ていて、JANコード: mod 10、奇数桁は×1、偶数桁は×3法人用マイナンバー: mod 9、奇数桁は×1、偶数桁は×2という違いしかありません。
おそらく、JANコード(mod 10)のアルゴリズムをベースに、「0は避けたいのでチェックデジットは9種類にしたい」「9種類にするならmod 9だ」「mod 9 だと、×3はダメだから、偶数桁は×2にしとこう」という安直な考え方で作られたんじゃないかと思ってしまいます。
パソコン屋としちゃ16進変換してCRC付加した方が簡単なんじゃと思ったり。1桁を8進数の0-7に限定でもすれば、ちょっと桁は増えるけど手間はかなり軽減するはず。
きちんと作成された mod 11 方式には数字を一つ間違っただけだと「必ず検出可能」という数学的にも検証済みで運用としても実証された利点がある。
それを中身を理解せずに変な改造して役に立たなくしたのが今回の話。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
思ったんだけど (スコア:0)
チェックデジットをアルファベットにしたらいいだけではないの?
Re: (スコア:0)
間違えても通ってしまうのが問題なんだからアルファベットにしたところで意味はないだろう
マイナンバーのSHAを入力してもらえばいい
入力ミスしても通ることはまずない
Re: (スコア:5, 参考になる)
ちゃんとリンク先を読め、で終わる話なんですが説明しとくと、個人用マイナンバーと法人用マイナンバーでは全然別のチェックデジット付加方法を採用してますが、
個人用マイナンバーは、mod 11 なので、チェックデジットに11種類の文字が必要ですが、それを数字で表現するために、余り0も余り10もチェックデジットを割り当ててます。その結果、チェックデジットが0の場合は、「余り0が余り10になったり、余り10が余り0になるような誤りは、チェックデジットが0のまま変わらない」から誤り検出できないので、誤り検出率が落ちるという問題があります。
法人用マ
Re:思ったんだけど (スコア:0)
不思議なんですが、そういう問題があることが明らかなのになんでチェックサムの計算方式ではmod 9やmod 11が主流なんでしょうか。かつてのrand関数みたいに特に理由もなく昔から使われているものが使われているだけなんでしょうか。
Re:思ったんだけど (スコア:3, 興味深い)
mod 11 には、全然問題はありません。mod 11 では11種類のチェックデジットが発生するので、数字1桁で表現できない、というデメリットがあるだけ。
それを、余り10も余り0もチェックデジットを0にする、という個人用マイナンバーのアルゴリズムが腐ってるんです。
「桁の入れ替わりを検出するため、個々の桁に固有の定数をかける」場合、その定数とモジュロが互いに素である事が重要です。例えば、mod 10 で、ある桁の数値に2をかけると、その桁では0(×2=0)と5(×2=10)のチェックデジットが一致することになってしまいます。
11は素数なので、「互いに素となるような数を多く作り出せる」という点でメリットがあります。
法人用マイナンバーの mod 9 は、まー論外ですね。そんな方法を使ってるとこはどこにもありません。主流でもなんでもないです。
JANコードと法人マイナンバーのアルゴリズムはよく似ていて、
JANコード: mod 10、奇数桁は×1、偶数桁は×3
法人用マイナンバー: mod 9、奇数桁は×1、偶数桁は×2
という違いしかありません。
おそらく、JANコード(mod 10)のアルゴリズムをベースに、「0は避けたいのでチェックデジットは9種類にしたい」「9種類にするならmod 9だ」「mod 9 だと、×3はダメだから、偶数桁は×2にしとこう」という安直な考え方で作られたんじゃないかと思ってしまいます。
Re: (スコア:0)
パソコン屋としちゃ16進変換してCRC付加した方が簡単なんじゃと思ったり。
1桁を8進数の0-7に限定でもすれば、ちょっと桁は増えるけど手間はかなり軽減するはず。
Re: (スコア:0)
きちんと作成された mod 11 方式には数字を一つ間違っただけだと「必ず検出可能」という数学的にも検証済みで運用としても実証された利点がある。
それを中身を理解せずに変な改造して役に立たなくしたのが今回の話。