パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

マイナンバーのチェックデジットは仕様上入力ミスを検知できない場合がある」記事へのコメント

  • by Anonymous Coward

    チェックデジットをアルファベットにしたらいいだけではないの?

    • by Anonymous Coward on 2016年07月25日 20時12分 (#3052810)

      間違えても通ってしまうのが問題なんだからアルファベットにしたところで意味はないだろう
      マイナンバーのSHAを入力してもらえばいい
      入力ミスしても通ることはまずない

      親コメント
      • by taka2 (14791) on 2016年07月25日 21時49分 (#3052860) ホームページ 日記

        ちゃんとリンク先を読め、で終わる話なんですが説明しとくと、個人用マイナンバーと法人用マイナンバーでは全然別のチェックデジット付加方法を採用してますが、

        個人用マイナンバーは、mod 11 なので、チェックデジットに11種類の文字が必要ですが、それを数字で表現するために、余り0も余り10もチェックデジットを割り当ててます。その結果、チェックデジットが0の場合は、「余り0が余り10になったり、余り10が余り0になるような誤りは、チェックデジットが0のまま変わらない」から誤り検出できないので、誤り検出率が落ちるという問題があります。

        法人用マイナンバーは、mod 9 を使って、チェックデジットは1~9の9種類(最上位桁にチェックデジットを配置しているので、0を避けたかったのだろうと推測されてます)。mod 9 では、「0 も 9 も、どちらも余り0」なために、mod には分配則が成り立つことを考慮してないような計算式のマズさにより、「各桁の数値が0から9になったり、9から0になっても、チェックデジットは変わらない」という問題があるのです。

        どちらも「チェックデジットを無理矢理数字一桁で表現しよう」としているためにダメになっちゃった例ですので、アルファベットにするというのも一種の解決策です。
        リンク先の記事では「大学入試センター試験の受験番号や試験場コードでは、「11で割った」結果を11種のアルファベットで表す」といった例も挙げられてますし、ISBNの旧形式(10桁)なんかもチェックデジットは0~9とXの11種類です。

        まあ、そこまでしなくても、最初から「数字一桁でも問題のない方法」を採用すればいいだけですけどね。JANコードで使ってるチェックデジット経緯算式は、今回の法人用番号とほぼ簡単同じ式ですが、mod 10 で、今回のネタのような問題はありませんし。

        親コメント
        • by Anonymous Coward

          不思議なんですが、そういう問題があることが明らかなのになんでチェックサムの計算方式ではmod 9やmod 11が主流なんでしょうか。かつてのrand関数みたいに特に理由もなく昔から使われているものが使われているだけなんでしょうか。

          • by taka2 (14791) on 2016年07月26日 13時13分 (#3053144) ホームページ 日記

            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にしとこう」という安直な考え方で作られたんじゃないかと思ってしまいます。

            親コメント
            • by Anonymous Coward

              パソコン屋としちゃ16進変換してCRC付加した方が簡単なんじゃと思ったり。
              1桁を8進数の0-7に限定でもすれば、ちょっと桁は増えるけど手間はかなり軽減するはず。

          • by Anonymous Coward

            きちんと作成された mod 11 方式には数字を一つ間違っただけだと「必ず検出可能」という数学的にも検証済みで運用としても実証された利点がある。

            それを中身を理解せずに変な改造して役に立たなくしたのが今回の話。

      • by miyuri (33181) on 2016年07月25日 20時13分 (#3052811) 日記

        とりあえず、ECCを付けて、入出力を機械任せにしてみてはどうだろうか。

        親コメント
      • by Anonymous Coward on 2016年07月25日 20時50分 (#3052834)

        >>「0」と「9」を取り違えた場合、間違いを検出できないという。

        まずこのリンクを読んでから書き込みして欲しい。

        親コメント
      • by Anonymous Coward

        高々12桁の10進数字に、最低でも20バイト必要なSHA [wikipedia.org]を使うとか全然意味ないだろ。

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー

処理中...