パスワードを忘れた? アカウント作成
23153 story
日本

「解読不能が数学的に証明された画期的な新暗号方式」が登場 111

ストーリー by mhatta
大丈夫なのかね 部門より

あるAnonymous Coward 曰く、

@ITの記事「「解読不能は数学的に証明済み」、RSAを超える新暗号方式とは」によりますと、「暗号技術利用の常識を打ち破る、まったく新しい暗号方式が現れた」のだそうです。記事によれば、このたび東京理科大学理工学部長兼量子生命情報研究センター長の大矢雅則博士が考案したという新暗号方式「CAB(Crypto Alarm Basic)」は、他の公開鍵暗号方式がCAB方式の特殊形と位置づけられることが数学的に証明されているのだそうで、大矢教授曰く「盗聴者が探索しなければならない鍵空間は無限大ですから、鍵を推定できる確率はゼロ」なのだそうです。このCAB方式は、量子コンピュータを使っても解くことができないそうで、コンピュータの計算能力が爆発的に上がっても、量子コンピュータが実現されても「解読不能」と言い切れるのだとか。

なんともはやすごい技術が登場したものだと驚きですが、学会発表や特許申請を一切行わずに開発を進め、クリプト・ベーシックという会社を立ち上げ事業化を進めているとのこと。大矢教授は「学会で発表をして名誉だけを受けるという選択肢もありましたが、われわれは会社にしました」と述べており、「今のところCAB方式を正当に評価できる方法や機関は存在しない」と豪語なさっているようなので、今後の成り行きが楽しみです。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • お! また「近未來通信」ですか!?
  • 疑問点 (スコア:4, 興味深い)

    by tks256 (30608) on 2008年04月13日 7時53分 (#1328837)
    これって、すでに公開されているんですかね?
    されてないなら最初の質問はスルーってことで。

    ・この暗号化方式は、アルゴリズムが公開されても耐えられる方式なのか。
     もしそうなら、なぜ特許を取った上で早急に学会に発表して検証を呼びかけないのか。
    ・復号化には必ず鍵が必要になるはずだが、ブルートフォースアタックにも耐えられるのか
    ・リンク先に「ほかの公開鍵暗号方式はCAB方式の特殊な場合」とあるが、
     逆に言うと特殊な場合には破られるのでは?
    • Re:疑問点 (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2008年04月13日 9時17分 (#1328868)
      > ・リンク先に「ほかの公開鍵暗号方式はCAB方式の特殊な場合」とあるが、

      リンク先記事からは「暗号方式がプログラマブルになってて、暗号プログラムをいつでも変更可能」と読み取ってみました。
      # 「ほかの公開鍵暗号方式はCAB方式の(暗号プログラムを決め打ちにした場合という)特殊な場合」

      が、これだと暗号プログラムを解析すれば暗号方式を解読できて、ほかの公開鍵暗号方式並みに暗号強度が落ちちゃいますね。何か違うのかな。

      というか未公表で未検証の暗号なのだから、リンク先自体も未検証の無意味な記事と言えるでしょう。暗号化の処理速度も、アルゴリズム未公表ではそれが速いか遅いか評価できません。

      野球のピッチャーの比喩で何を納得したのだろうか、この記者は。
      親コメント
      • Re:疑問点 (スコア:2, おもしろおかしい)

        by YOUsuke (6796) on 2008年04月13日 14時50分 (#1329070) ホームページ 日記
        >野球のピッチャーの比喩で何を納得したのだろうか、この記者は。

        野球のピッチャーも暗号方式も本番にならなければ実力はわからない。
        しかし野球のピッチャーの開幕前情報は需要がある。
        だったら暗号方式だって詳細がわからないまま報道したっていいじゃないか!

        と、納得したんだろ。
        --
        妖精哲学の三信
        「だらしねぇ」という戒めの心、「歪みねぇ」という賛美の心、「仕方ない」という許容の心
        親コメント
      • by rose (10717) on 2008年04月13日 9時58分 (#1328890)
        プログラマブルではなく、暗号方式(関数)自体が鍵になっているイメージじゃないでしょうか。
        鍵が得られればそりゃ解読可能でしょう。

          > 野球のピッチャーの比喩で何を納得したのだろうか、この記者は。
        納得するもしないも、記者としては伝えるのが目的ですし・・・
        親コメント
      • by hkt (2602) on 2008年04月13日 11時56分 (#1328970)
        暗号方式をいくらでも変更可能という場合は encrypt/decrypt プログラムをかくのが超大変そう(つか無理).
        暗号化方式は無限にあるといってもプログラムのバイナリサイズは有限ですがな…
        そもそもどの暗号化方式でencryptしたのかをどうやって相手に渡すんだろう?

        どう考えても提案方式はまともに機能しない方式な気がしますけどどうなんだろう?
        親コメント
  • by Anonymous Coward on 2008年04月13日 7時12分 (#1328830)
    「なあ弟者、世の中に暗号化アルゴリズムはほぼ無限にあるよな」
    「そうだな兄者、無限ではないと思うがまあたくさんあるな」
    「そこでだ、どのアルゴリズムを使ってるか隠せば誰も読解できないぞ」
    「さす(ry
  • おもうがままにツっこむと

    * 絶対解けない暗号といえばワンタイムパッドがあるような。
    * 暗号アルゴリズムの非公開による強度は考えてないんだろうけど、昨今の暗号の考え方に沿ってない(このあと公開される保証があるのか?)
    * 「聖書を同じ長さの鍵で~」って、暗号化の負荷を言ってるだけだろうけど、鍵が長すぎるんだが...というか本文と同じ長さの鍵って...
    * 結局短い鍵じゃ総当りで解かれるし、長いと配送問題になる
    * 鍵交換とかで鍵を用意するしかないのか?
    * 0/1byte圧縮系の匂いはどうにかならんのか?(違

    とかとか。

    いや処理が軽いってのはいいんですが、逆言えば総当りでのチェックも早いだろうと思うのです。
    強度がどうか?とはまた別に悩ましい所と思ったり。

    # 同じ鍵で沢山メッセージやりとりしても、類推できないことが保証できるとかあれば強いと思いますが。
    # もちろん解読のための短縮した処理が無いということの保証もあるといいです。
    --
    M-FalconSky (暑いか寒い)
    • 補足

      ここで、「総当り」は全鍵空間のチェックというよりは、最小の鍵長から始めて全てなめるようなことのつもりでした。
      「ブルートフォース:力任せ」と書くべきでしたかね...

      # 中途半端というか素人が齧っただけなのでID
      --
      M-FalconSky (暑いか寒い)
      親コメント
    • by s02222 (20350) on 2008年04月13日 17時54分 (#1329157)
      >* 「聖書を同じ長さの鍵で~」って、暗号化の負荷を言ってるだけだろうけど、鍵が長すぎるんだが...というか本文と同じ長さの鍵って...

      その後にも8ギガビットの鍵やらなにやら出てきますし、何となくxor取ってるだけのような気が。
      “[鍵(ランダムなビット列)] xor [本文]”な暗号化って解読しにくさ最強ですし。その“ランダムなビット列”をユーザ定義の関数(これが鍵)で生成するとかそう言う話かな?

      #別にxorじゃなくても良いんですが基本的に何かそんな感じみたいな(適当)。
      ##でもそれじゃ、任意の公開鍵暗号方式はこの手法の特殊型だ、とは相容れないか。
      ###やっぱいつものデマかなぁ。
      親コメント
  • by kmra (33703) on 2008年04月13日 10時55分 (#1328935) 日記
    リンク元記事より引用:

    われわれはもともと数学研究者であって、暗号とかソフトウェアとは関係がないんです。

    暗号研究者たちが活発に議論している場所とは全然かけ離れた地点での研究が、偶然暗号に使えることが分かった。ですから、従来の暗号方式とは枠組みがまったく異なるのです。

    CAB方式は、まだ実績がなく事実上未公表の技術だ。情報が公になっていくにつれて、専門家たちがどう反応するかは未知数だ。
    また、その安全性についても、理論的裏付けがあるとはいえ今後は専門家による検証が欠かせない。
    リンク元記事を読んでみたのですが、暗号の専門家がかんでいない様に見えます。
    どれぐらい価値のある暗号なのか多方面から鑑定・検証されていないという認識で正しいでしょうか?

    とにかく、本人も投資家も採用企業も大きな賭けをしているということはわかった。
    • by kmra (33703) on 2008年04月13日 11時38分 (#1328962) 日記

      専門家による検証やビジネスでの展開を考えると、どんなに早くても実利用がスタートするには、まだ数年かかるだろう。しかし、もし今後、「CAB方式は解読不能と証明済み」ということが第三者によって確かめられ、その実用性が認められれば、CAB方式は公開鍵暗号方式の発明に匹敵するインパクトをデジタル社会に与える可能性があるかもしれない。
      前提:
      ・実利用がスタートするあまで数年はかかる
      ・第三者によって解読不能の証明が確認される
      ・実用性が確認される

      結論:
      ・公開鍵方式の発明に匹敵するインパクトを社会に与える可能性がある
      かもしれない

      元記事作成者はこれだけ念押しをしているのは意志があらわれているから?
      それとも、東スポ的記事のお約束?
      親コメント
    • 専門以外の学者がすごい発見をしたとかっていうと どうしてもポンズらの常温核融合の空騒ぎを思い出すな。
      親コメント
  • 始める前から (スコア:2, 参考になる)

    by 0093 (29457) on 2008年04月13日 11時04分 (#1328941)
    中央大学がこんなこと [chuo-u.ac.jp]始めるみたいですけど,もしかして始める前からお役ご免?
  • なぜか弱いパスワードが頻繁に、変更されることなく使用されていたりする。
    だから

    >CAB方式では、その関数自体が無限個の中から利用者が自由に選べて、いつでも変えられる

    とは言っても、利用者が関数について考慮するのが面倒であまり強くない関数が使いまわされたりしないだろうか。暗号強度的に強めの関数が定期的に変更されるように実装する仕掛けが必要なのではないだろうか、などと気になったりする。

    # 過去記事#9)テクノロジーは私達を追い越しているのでしょうか? [srad.jp]も一緒に読もう
    --
    /.configure;oddmake;oddmake install
  • 確か昔、無限にデータ圧縮できると言い張っていた詐欺師も、同じような事を言っていたな。
    --
    fjの教祖様
  • by SteppingWind (2654) on 2008年04月13日 10時50分 (#1328927)

    数学的に無限(アレフ0)のサルに試行させれば解けそうな気がするのですが. それともアレフ1じゃないと解けないのかな?

    # 物理的に(事実上)解けないってのなら話は分かるのですけど

  • by shoji12 (14093) on 2008年04月13日 12時36分 (#1328994)
    鍵を生成するソフトは、無限大の鍵を生成できると証明されてない。
    いつかは循環してしまうのではないか。
    鍵生成ソフトと鍵解読ソフトがハックされても大丈夫なのか?
  • by Anonymous Coward on 2008年04月13日 13時21分 (#1329023)
    FSAngoとか思い出した
    http://www.fsi.co.jp/project/s/products/fsango/index.html [fsi.co.jp]

    たまにこの手の(自称)画期的技術とか現れるんだけど、その後ぱったり聞かなく
    なったりするんですよね。

    なんで話題にならなくなるのか私なりに想像するに、

    (1)全くナンセンスな話なので、他の人からは相手にされていない。ただ、小者
    過ぎて誰かが反論もしてくれないので、第三者には、根本的に間違っているのかす
    ら判らない。反論はあるのかも知れないが、一般的な記事にならないので、知りよ
    うがない。
    (2)1社独占の技術が新参しても、普及する事はとても困難。従来のやり方を覆
    して入っていくのは、よほど魅力が必要で、それはかなりハードルが高い。新しい
    コストを払ってまでも入れたいと思うのは、よほどの事が無いと駄目。最初から有
    料化されてる物が普及した例って、あるのかな?特に暗号化技術は添え物であり、
    無限のコストが許されるものじゃない。
    (3)とても運が無い

    どうも、本件もこの轍を踏んでいるような気がしてなりません。

    #検索して出てきたその後のFSAngo
    #http://techon.nikkeibp.co.jp/d-ce/2000/20000128scis5.html
    #>多重アファイン鍵による暗号の一部に致命的な欠陥,連続使用で平文がそのまま露出

    あと、一般論ですが、真摯な科学者ほど生半可な事で「確率はゼロ」とか言わないと
    思うんですけどね。
  • > 盗聴者の探索しなければならない鍵空間は無限大ですから、鍵を推定できる確率はゼロです
    ここが厳密には嘘になります。恐らく本人も嘘であることは分かっていると思いますが、一般人に本方式の有効性を説明するのには良い言葉ですよね。こういうのは嘘じゃなくて方便、と言うのかな?

    ちなみに本当0ではないことの証明の概要は下記の通り。

    鍵の集合を{K_1, K_2, ... }とし、各鍵K_iが選択される確率をP(K_i)とします。たとえば単順な攻撃として、
    確率1/2^kで鍵K_kを予測する攻撃者が居たとしますと、この攻撃者が鍵を推定する確率は、
     ∞
     Σ P(K_k)/2^k > 0
    k = 1
    となります。実際はもっとましな攻撃者の可能性があるでしょう。
    --
    Best regards, でぃーすけ
  • by johndoe (3028) on 2008年04月13日 21時36分 (#1329224) 日記
    解読不能ってことは復号不能ってことじゃないのか?
    へべれけに酔ったやつの書いたメモとかそういうのじゃないのか?
  • by nim (10479) on 2008年04月13日 23時42分 (#1329258)
    解読不可能な暗号化方式を考案してしまいました。

    1. 平文を用意します。
    2. 手元の広辞苑を開いて、ランダムに開いたページから適当な長さの文字列を取り出します。これが暗号文になります。
    3. その暗号文を通信相手に送ります。

    この暗号文の何処を見ても、元々の平文に関係する情報は存在しないため、
    この暗号文を盗聴しても決して元の文を復元することはできません。
    ちなみに、本来の通信相手は、以下のような手順で復号します。

    1. 暗号文を受け取ります。
    2. 事前に入手しておいた、平文と同じ文字列を取り出します。

    この、「平文と同じ文字列」が、復号した文となります。
    • Re:実は私も (スコア:1, おもしろおかしい)

      by Anonymous Coward on 2008年04月14日 9時17分 (#1329347)
      1. 営業を用意します。
      2. 手近な上司を用いて、ランダムに開いた経営会議から適当な金額のプロジェクトを取り出します。これが暗号文になります。
      3. その設計書を子会社相手に送ります。

      親コメント
      • Re:実は私も (スコア:2, おもしろおかしい)

        by Tatenon (20311) on 2008年04月14日 10時15分 (#1329375) 日記
        復号手順

        1.暗号を受け取ります。
        2.親会社に電話をかけて担当者にアポをとります。
        3.出かけていって担当者から内容を聞き出し暗号を補完したりメモを取ったりします。
        4.帰って清書します。

        これで復号完了です。
        この暗号化・復号化が不完全な実装となってるエンコーダー・デコーダーが多々あり、
        その後『デスま』と呼ばれる悲惨な状況を作り出すことがあります。

        # 「ま」だけひらがなにすな。某少年漫画みたいやないか。
        ## じゃ「です☆まーち♪」
        # ・・・一瞥しただけで殺意を覚える字面だな。

        親コメント
  • 関数を自由に選べるってのは、鍵に関数も含まれている、と考えられる。 鍵の長さが有限なら、絶対にブルートフォース可能だろう。
  • by naono (10959) on 2008年04月14日 21時24分 (#1329937)
    記事の字面から推量するに決定不能問題と絡めてみました、という程度かしら
    解読する関数を作ることができない、とは言えるのかもしれませんが
    力任せに解けないという意味にはならないのでしょう。

    とはいえ複雑な鍵を作るのも容易と思われるので、
    それなりに実用性があってもおかしくはない気もします。
typodupeerror

ソースを見ろ -- ある4桁UID

読み込み中...