アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
疑問点 (スコア:4, 興味深い)
されてないなら最初の質問はスルーってことで。
・この暗号化方式は、アルゴリズムが公開されても耐えられる方式なのか。
もしそうなら、なぜ特許を取った上で早急に学会に発表して検証を呼びかけないのか。
・復号化には必ず鍵が必要になるはずだが、ブルートフォースアタックにも耐えられるのか
・リンク先に「ほかの公開鍵暗号方式はCAB方式の特殊な場合」とあるが、
逆に言うと特殊な場合には破られるのでは？
Re: (スコア:1, すばらしい洞察)
リンク先記事からは「暗号方式がプログラマブルになってて、暗号プログラムをいつでも変更可能」と読み取ってみました。
# 「ほかの公開鍵暗号方式はCAB方式の(暗号プログラムを決め打ちにした場合という)特殊な場合」
が、これだと暗号プログラムを解析すれば暗号方式を解読できて、ほかの公開鍵暗号方式並みに暗号強度が落ちちゃいますね。何か違うのかな。
というか未公表で未検証の暗号なのだから、リンク先自体も未検証の無意味な記事と言えるでしょう。暗号化の処理速度も、アルゴリズム未公表ではそれが速いか遅いか評価できません。
野球のピッチャーの比喩で何を納得したのだろうか、この記者は。
Re:疑問点 (スコア:0)
このS-boxを鍵から生成することは昔から行われているが、弱いS-boxを生成する鍵が存在することがあり、実装ではそういう鍵を検出するようにすることがある。
たとえばblowfishは2^14につき1つの確率で弱いS-boxを生成する鍵が存在するため、鍵生成時にこのような鍵は拒否しなければならない。
この提案手法だが、鍵から生成する「モノ」をS-box以外にも広めたということならば、弱い「モノ」を生成する可能性については考慮しなくていいのだろうか。
弱い暗号化関数を作ってしまう鍵を鍵生成時に検出するというのは、従来の暗号手法において弱いS-boxを生成する鍵を鍵生成時に検出するより困難なようにみえる。
仮にこの提案手法が本当に使えるのなら、現在は非対称は非常に遅いため「非対称でセッション鍵を交換し、続いて対称鍵にセッション鍵を使い、定期的にセッション鍵も交換する」という方式が不要になり、最初から非対称鍵を用いストリーミングを行えるということになるのだろう。
いずれにせよ、camelliaのように特許をとって学会で公表してNESSIEやCRYPTRECに載せなければ認めて貰えないだろう。