本文章は共立出版 Bit 2000年4月号 (pp17-pp24) に掲載された 『AESファイナリストをめぐって〜暗号最新動向/鈴木裕信』を Web用に編集したものです。

AESファイナリストをめぐって
〜暗号最新動向〜

鈴木裕信

hironobu at h2np.net

DESからAESまでの道

暗号アルゴリズムとしてDESは広く知られているが、正式にはData Encryption Standardという名称である。これは1970年代米国商務省が政府の標準化暗号と して公募し、そして選定した暗号アルゴリズムである。

1960〜70年代前半にかけて米国内では既にデータプロセッシングのための各種 の"商用"暗号処理システムが存在していた。ここで商用とわざわざ強調するの はコンピュータが一般に使われ、そしてデータプロセッシングのセキュリティ として暗号技術が必要になる以前は暗号技術とは軍事機密を扱うためのごく限 られた世界の技術だったからである。60年代も終りになって軍事技術として発 展した暗号技術とは違う商用システムとしての暗号技術の必要性が出て来たの である。

Bruce SchneierのApplied Cryptographyによればそこでは各種の商用暗号シス テムが売られるわけだが、多くは小さな会社が作った暗号システムで利用する 暗号アルゴリズムもバラバラで互換性がなかったらしい。

現在においてもスネークオイル・サイファー(Snake Oil Cipher)と俗称される ようなインチキな暗号システムが多数存在する。これは筆者の想像ではあるが オープンでアカデミックな暗号技術が現在ほど発達していなかった時代では、 今にもまして数多くの紛い物が存在していたであろう。

1972年にNBS ( National Bureau of Standards)がコンピュータとデータ通信 保護のための標準化を起案し暗号アルゴリズムを公募した。NBSは現在のNIST ( National Institue of Standards and Technology)の前身の組織である。し かし1972年には、まったく応募がなかった。そこで1974年に再度公募をかける。 そこでやっとIBMからの応募があった。それがDESのベースとなるLuciferであ る。

Luciferが直接DESとなったわけではない。NSA (National Security Agency)の 手により評価され少し改造を加えられてDESとなっている。このため長い間、 NSAの手によりDESにトラップドアが仕掛けられたのではないかと疑いをかけら れることになる。NSAの暗号安全性評価が正しい評価であり、そしてより安全 性を高めるための変更であっても公表はできない状況にあった。なぜなら Luciferに対しての変更理由を公表するということは国家安全保障上の問題と して最高機密レベルである暗号解読技術の情報を公表することと同じであるか らだ。

1990年代に入ってアカデミック分野での暗号分析理論の発展[1]により分かっ てきたことであるがDESは当時としては十分に安全な設計であったといえよう。 これは偶然だったわけではなく、当時の〜つまり20年前であるが〜DESの設計 者達はこの差分攻撃方法と呼ばれる方法を既に知っていて対応済だったのだ。 しかし、このことはBihamとShamirの論文発表後まで沈黙を守ってきた。国家 安全保障上の問題として今まで公表ができなかったのだろうということは想像 に難くない。

1976年に連邦政府で暗号を用いる際の標準化暗号DES (Data Encryption Standard)を決定した。DESは1977年にFIPS PUB 46という規格として正式に発 行した。

暗号の歴史においてDESの画期的な点は暗号アルゴリズムを完全に公開した点 である。FIPS (Federal Information Processing Standard)という連邦の規格 として標準化し、そして商用システムがそれをサポートしなければならないの で、当然暗号アルゴリズムの内容は広く公開しなくてはいけない。したがって 「アルゴリズムが公開されていてもなお安全である」ということが必須の条件 となる。これ以降、暗号アルゴリズムの安全性を証明するには暗号アルゴリズ ムは公開されていることが前提となったと言える。

この「アルゴリズムを公開してもなお(理論的な面で)安全である」というDES を現代暗号の出発点だと考える研究者は多い。ちなみに筆者は1949年に発表さ れたC. E. Shannonの"Communication Theory of Secrecy System"を現代暗号 の出発点だと考えている。

これらのDESの歴史から安全な暗号であるという証明のためには、アルゴリズ ムが公開されていること、そしてアカデミックな形での安全性分析が必要であ るという点が学び取れる。

なぜAESなのか

1970年代の標準化暗号DES決定から次の標準化暗号AESを決めるプロセスに入る まで30年近くを経ている。コンピュータ・テクノロジー進化の時間の流れは速 く、1年という月日が現実世界の7年に相当する。いわゆるドックイヤー(犬齢 での1年の加齢は、人間の7歳分に当たる)である。それでいくと30年という月 日はコンピュータテクノロジーの進化ではの200年以上の時間の流れになる。 このような異常な事態は政治と技術の歪みによって引き起こされた。1980年代 末期から1990年代中期にかけて米国内政治勢力の中で暗号規制の勢力が強かっ たためである。暗号アルゴリズムを隠し、かつ、その一方でトラップドアを開 けるための鍵を国家が管理するというクリッパー計画である。

1990年代も半ばを過ぎると、そのようなクリッパー計画のような一部政治勢力 が主張するような無謀な計画はユーザからもコンピュータ業界からも拒絶され た。そもそも既に1970年代にアルゴリズムもなにもすべて公開するというコン ピュータ時代における暗号技術のパラダイムを構築しているのだ。

それからさらに10年も20年も経ってさらにコンピュータとネットワーク通信の 飛躍的発達してしまっている時代に何十年も前の時代に逆行するようなことが 可能であるという考え方自体に無理がある。またインターネット時代において は、そもそもこのような非民主主義的なことが成立する余地はない。密室政治 時代には一部政治勢力が発するプロパガンダも効果があっただろうか、インター ネット時代ではすべてが白日の下に晒されるからだ。

コンピュータとネットワーク通信の飛躍的発達と書いたが、それは同時に1970 年代に設計されたDESの寿命を縮めることも意味している。1990年代に入り暗 号解読理論だけではなく[2]、プロセッサ能力、広域ネットワーク分散計算技術が 飛躍的に進歩した。特にインターネットに接続された無数のパソコンが計算資 源として利用できるようになったことは大きい。

このような背景において今まで安全であったDESも徐々に安全性が薄れてきて いる。最新の暗号分析理論では0.73 x 2^43程度の平文/暗号文のペアで解読で きるようになり[3]、ブルートフォースでの攻撃では大量のDES鍵探索専用LSI を用いたシステムDeep Crackが平均4.5日で解読できるようにまでなっている (注: ここでの解読とは解読できる確率が50%を上回ることをいう)。

DESの安全性が低下しているため、さらに高い安全性を求めるシステムではDES を3回繰り返すTriple DESが利用されるようになる。Triple DESはANSI X9.17 とISO 8732という規格にも既になっている。しかし、DESを3回繰り返すのは今 日の高速なCPUであってすら処理が重い。

今日のインターネット時代において暗号というのは、ありふれたデータ保護技 術の1つに過ぎないわけだが、その処理にTriple DESを使うには安全ではあっ ても処理効率が悪くコストが割りに合わない。かといってDESは時代遅れにな りつつある。その背景の中でTriple DESに変わる安全でかつ処理効率の良い暗 号が乱立しつつあった。またここでもデータ互換性の問題が出て来たのだ。こ れは1970年代にDESを必要とした時代背景と同じである。

米国商務省はDESにかわる次世代標準暗号AESの選定に着手した。

AESの要求仕様と選定プロセス

AESに対する要求仕様と選定のプロセスの流れをざっと説明しよう。まず技術 的な要求仕様の方を先に説明すると以下のようになる。

  • 共通鍵暗号であること
  • ブロック暗号であること
  • ブロックサイズが128bitをサポートしていること
  • 鍵長が128bit、192bit、256bitがサポートされていること

あとAESとして評価期間中における知的財産権の権利停止、AESとして決定した 場合、知的財産権行使を放棄する(無償使用許諾)ことなどが求められる。提出 には実際に動くCとJavaコード及びライセンスに関する契約書類などが必要で ある。評価プラットフォームは以下の通り。

  • IBM PC互換機, CPU Pentium Pro 200Mhz, メモリ64MB
  • Windows 95, Borland C++ 5.0コンパイラ, JDK 1.1

選定プロセスは次のようになっている。

  • 1997年 1月 -- 米国商務省(NIST)がAES選定計画発表
  • 1997年 4月 -- AES Workshop開催
  • 1997年 9月 -- AES 候補受付アナウンス
  • 1998年 6月15日 -- 提出〆切
  • 1998年 8月20-22日 -- 第一回AESカンファレンス ラウンド 1の評価期間に入る
  • 1999年3月 22-23日 -- 第二回 AESカンファレンス
  • 1999年4月 15日 -- ラウンド 1終了
  • 1999年8月9日 -- ファイナリスト発表 ラウンド2の評価期間に入る
  • 2000年4月 13-14 -- 第三回AESカンファレンス
  • 2000年8月 -- AES決定

AES レーススタート

AES候補者発表会である第一回AESカンファレンスは1998年 8月20から22日まで 米国カルフォルニア州ベンチュラという小さな町のホテルで行われた。世界各 国から参加者200名ほどが集まった。AESに応募した暗号アルゴリズムは全部で 21あった。書類の不備や応募したコードが指定プラットフォームで動作しなかっ たなどの理由で6つが受け付けられなかった。AES候補は次の通り(この状況に 関して1998年12月号Bitに筆者が書いた"AES Conference/CRYPTO 98訪問記"を 参考のこと)。

ここから衆人環視の中で行われている残酷な生存競争が開始されることとなる。 AESレースは『良い点を見つけて救い上げる』ための場ではなく『欠点を見つ けて蹴落とす』ための場なのだ。

暗号アルゴリズム名国名開発者
CAST-256カナダ Entrust Technologies, Inc.
CRYPTON 韓国 Future Systems, Inc.
DEAL カナダ R. Outerbridge, L. Knudsen
DFC フランス CCNRS - Ecole Normale Superieure
E2 日本 NTT
FROG コスタリカ TecApro International S.A.
HPC 米国 R. Schroeppel
LOKI97 オーストラリアL. Brown, J.Pieprzyk, J. Seberry
MAGENTA ドイツ Deutsche Telekom AG.
MARS 米国 IBM
RC6 米国 RSA Laboratories
Rijndaelベルギー J. Daemen, V. Rijmen
SAFER+ 米国 Cylink Corporation
Serpent 英国/イスラエル/ノルウェー R. Anderson, E.Biham, L. Kundsen
Twofish 米国 B.Schneier, J.Kelsey, D.Whiting, D.Wagner, et al.

早い時点の脱落者

暗号アルゴリズムに問題があればこのレースからは脱落する。ここでの解読の 意味は、ブルートフォースアタッック(全部の鍵空間をしらみ潰しに探す)より も少ない計算量で鍵を見つけることができるということを意味している。早々 と脱落していった暗号はLOKI97、DEAL、MAGENTA、FROGである。

LOKI97とFROGは第一回AESカンファレンスで発表する以前に既に解読方法が発 表されている。DEALは同じ発表の場で提案者から解読方法が発表された。 MAGENTAは第一回AESカンファレンスで発表者が発表し質疑応答を行っている時 点で解読方法がまとまってしまった。 HPCはそれ以前の問題としてわざわざ評価する価値もないと言われていたので、 これもこの時点で脱落である。

第二回AESカンファレンスでは数々の分析が発表され、NISTがファイナリスト 選考のための判断基準に利用する基本データとなった。

ファイナリスト発表

ラウンド1が終り5つの暗号アルゴリズムがファイナリストとして選出された。

MARS RC6 Rijndael Serpent Twofish

AESの選定計画では5つあるいはそれ以下のアルゴリズムが選出されラウンド2 の評価に進むということが記されてあった。短い期間でどう評価するしていい のか、また基準は妥当なのかなど難しい点があるのは言うまでもない。そこで 一時期は5つではなく、問題の発生していないすべての暗号アルゴリズムをラ ウンド2に進ませるのではないかという憶測も流れた。

以下は NISTが発表した"Status report on the first round of the development of the advanced encryption standard"(NISTのWebサイトより入 手可能)をベースにファイナリスト選出について考察していきたい。このドキュ メントは先に紹介したAESのWebページを辿って入手できる。

安全性に対するクレーム

NISTが安全性に大きな問題があると指摘された暗号アルゴリズムは以下の通り。

  • 理論的に解読可能 --- DEAL、LOKI97、MAGENTA
  • 解読可能な弱い鍵が多数ある --- FROG、HPC

これら5つの暗号はこの時点で脱落である。

さらに小さい点ではあるが問題がわかったと指摘されている暗号は以下の通り。

  • CRYPTON -- 256bit鍵長では多くの弱鍵がある
  • SAFER+ -- 256bit鍵長さではrelated-key攻撃と meet-in-the-middle攻撃に対し弱さがある

CRYPTONとSAFER+はどちらも256bit鍵長ではこのような解析がされているわけ であるが、これらは大きなマイナスポイントとなるだろう。

それ以外の新しい暗号分析(とNISTが示している)の指摘は次の2つである。

  • DFC -- 6ラウンドまでの解読可能
  • E2 -- 9と10ラウンドまでの解読可能

基本的には後に述べる安全性のマージンとの兼ね合いで、十分に安全性の マージンが取っているのでこれらの指摘に対しては大きな問題とはならない。

しかしそれ以前の問題として、そもそも E2の安全性に関してNISTは間違えて理解している。 NISTは9ラウンドと10ラウンドに言及しているが、NISTが根拠としている論文 [4]ではE2の構造を変更した上で9ラウンドと10ラウンドを実験的に分析してい るに過ぎない。だからE2自体には当てはまらないはずである。同論文のセクショ ン5.3をきちんと読めばすぐにNISTが間違って解釈しているということがわか る。

    この原稿を書き終った後にこの点に関してNTTがクレームをつけており、 NISTがその間違えを認める追加ドキュメントがあることを知合いから 教えてもらった。 リポートの下に小さくリンクが張っている。筆者が見過ごし ていたのと同じに、この分かりづらいaddendaまで目を通す人はごく 僅かだろう。

    URL http://csrc.nist.gov/encryption/aes/round1/r1report-addenda.htm

またDFCに関しては、DFCが既に出している安全性証明とは矛盾はしていない。

予選リーグ作成

レポートをよーく読んでいるとNISTは似たような暗号同士を比較して優劣をつ けているのが行間から読むことができる。つまり、結果的にではあるが、最終 選考のために暗号アルゴリズムを似たもの同士でグループを作りその中から勝 ちのこりが決勝にあがるという、まるでサッカーのワールドカップようなこと をやっている。グループ分類すると以下のようになる。MARSとRC6に勝ち上が りのシード権を与えているようなことをしている。

  • 第一グループ --- CRYPTON E2 Rijndael Twofish
  • 第二グループ --- CAST256 SAFER+ Serpent
  • 第三グループ --- DFC
  • 第四グループ --- MARS
  • 第五グループ --- RC6

参考として分類について言及すると、暗号アルゴリズムの分類方法は色々ある が、もし暗号アルゴリズムの主な構造で分類すると次のような分類になる。

  • Feistelタイプ --- Twofish E2 DFC
  • Feistel拡張タイプ --- CAST256 MARS RC6
  • Substitution-Permutation Networkタイプ --- Rijndael CRYPTON Serpent SAFER+

処理効率

処理効率に関しては以下のポイントをもって判断している。

  • 8/32/64ビットCPU上での効率
  • 利用するRAM/ROMのサイズ
  • 鍵スケジュール処理
  • Low-end/High-endのICカードでの効率

面白いのは、今日ではかなり暗号アルゴリズムでは当り前になってきた並列処 理化による処理効率の向上は問わない。並列処理化はチップ化した時に効果が あるがパソコンなどの汎用CPU上では効果がないためだと思われる。

なお処理効率に関してNISTは自分の所で計測しただけではなく第二回AESカン ファレンスで発表された複数の発表から処理効率のデータを用いて比較してい るので、かなり公平ではないかと筆者は判断する。

C言語実装での処理効率

ここではCで書かれたコードを32bit CPUで動かした場合、64bit CPUで動かし た場合にどの程度の差があるかをリストアップしてみる。まず、32bitCPUと 64bitCPUの速度を比べると次のようになる。

    32bitと64bitパフォーマンスに関しては[4] を参考とした。 他にもNIST以外の第三者評価としてB. Gladmanの評価などもあるが、 これも同じような傾向を示す。

暗号アルゴリズム 鍵セットアップ
Pentium Pro
暗号化
Pentium Pro
暗号化
DEC Alpha
RC6 1700 260 467
MARS 4400 390 478
Twofish 8600 400 360
Rijndael 850 440 340
CRYPTON 955 476 408
CAST-256 4300 660 600
E2 2100 720 471
Serpent 2500 1030915
SAFER+ 4000 1400656
DFC 7200 1700304
DEAL 4000 260002528
グラフは ここをクリック

32bit CPUではRC6が飛び抜けて高速なのがすぐにわかる。MARS、Twofish、 Rijndael、CRYPTONがほぼ同一線上、CAST256とE2がほぼ同じレベル、Serpent がやや遅れて続き、SAFER+、DFCがつづき、DEALが最後である。DEALは極端に 遅いので、この時点で脱落だろう。

64bit CPUではDFCが一気にトップに踊り出る逆転現象が見られる。逆にRC6は 平凡なレベルに落ちてしまう。CPUの違いに依らず一定のレベルを保っている のはTwofishとRijndaelである。ちなみにE2は32bitでも64bitでも不動の7位を キープしている。

Java言語実装での処理効率

Javaで書いて動かした場合、どれくらいの差が出るかをリストアップしてみる。 ここではAESの提出の時にテストとして用いられているモンテカルロテスト (Monte Carlo Test)を行いその処理速度を比較している。

暗号アルゴリズムMCTkbit/s
RC6 5061
MARS 3284
E2 2934
CRYPTON 2710
Sperpent 2544
Twofish 1729
CAST-256 1213
SAFER+ 811
DEAL 664
Rijndael 513
DFC 35
フラットフォームSun Ultra Enterprise 2
UltraSparc 200Mhz,256MB RAM, Solaris, Java technology
interpreter, Just-In-Time compiler

ここでもRC6がトップである。それにMARSがつづくという展開になっている。 E2がかなり健闘しているが、実はここに落し穴がある。実はE2は高速化するた めに大量のROMを消費している。E2以外のプログラムはだいたい10KBぐらいか ら20KB程度しかROM使っていないのに対しE2だけは275KBという極端にROMを消 費している。この時点でE2は脱落である。

これはインプリメントの時に高速化をあせるあまりすべてを事前にメモリ中に 押し込めておこうという作戦に出たのかも知れない。しかし、これは大きな戦 略ミスだと言わざるえない。Javaの使われ方を考えればどう考えても275KBと いうサイズは致命的だ。セキュリティやメンテナンスの問題を局所的に還元さ せるためEコマース関連ではJavaを多用している。Javaで実装する時はネット ワークからJavaのコードをロードして使うことを想定しなければいけないし、 またJavaCardのようなICカード上の動作にも問題が出る。

この点に関しては先のCRYPTO 99で一緒になったE2関係者に質問してみた。 NISTが「プラットフォーム非依存なことを利用し、それぞれのアルゴリズムの 相対的な性能を評価することに用いる」と説明していたこと、そして、Javaを 使う環境は最新のPentiumm やSUN SPARCのようなハイエンド・ディスクトップ・ コンピュータを想定していたため、メモリをこの程度つかっても問題がないだ ろうと判断して、速度を上げる方に振ったらしい。

しかし、いくらNISTがメモリ使用量に言及しないとはいえJavaでプログラムを 書くときの常識は当然求められるだろう。これが他のアルゴリズムの2倍とか 3倍とかのサイズ範囲なら、まだ「メモリ使用量について言及しないNISTが悪 い」と抗議もできるだろうが、ここまで極端なメモリ使用量だと完全にアウト である。もし筆者がAES提出前にこのJava実装をチェックができたらきっと良 いアドバイスもできたろうにと思うと非常に残念である。

もう1つDFCの速度が極端に遅い。なぜ、そうなったかわからないが、Javaでの 実装に慣れていないのか、何か勘違いして実装してしまったのだろうか。この 数字は極端すぎる。DFCもここで脱落である。

セキュリティマージン

もっと議論を呼ぶのはこのセキュリティマージンの評価だろう。各暗号アルゴ リズムのラウンド数に、最低限安全が保てるだろうラウンド(推定)と現在想定 できるアタックの最大ラウンド(実際、あるいは推定)で比較している。下記表 は攻撃可能だと推定できるラウンド数に対する安全マージンでソートしている。

アルゴリズム名ラウンド数攻撃可能だと
推定できるラウンド数
現時点で攻撃
可能なラウンド数
攻撃可能に対する
安全性マージン率
現時点での
安全マージン率
Serpent32171588%113%
MARS32201260%166%
Rijndael108625%66%
CAST-25648402020%140%
E21210920%33% ←クレームあり
Twofish1614614%166%
SAFER+87514%60%
CRYPTON1211109%20%
RC6202116-5%25%
DFC896-11%33%

    マージン率 (%) = (ラウンド数 - 攻撃可能ラウンド数)/ 攻撃可能ラウンド数

    クレームあり: E2の正当と思われる評価(筆者による)

条件 ラウンド数 攻撃可能だと
推定できる
ラウンド数
(筆者による推定)
現時点で攻撃
可能なラウンド数
攻撃可能に対する
安全性マージン率
現時点での
安全マージン率
E2の正しい
安全マージン評価
12 9 7 33% 71%
さらに「初期変換」
「最終変換」の効果
を認めた場合
(厳しく評価)
149755%100%
MARSと同様に
評価した場合
169777%128%

NISTの誤り

ひつこいようだがNISTはE2の安全性に関する理解を間 違えていることを再度指摘したい。先にも書いたが攻撃可能なラウン ド数を勘違いしているのだ。現状では7ラウンドまでしか攻撃可能ではない。 それを元に攻撃可能だと推定できるラウンド数として2ラウンドを加える(この 値は筆者の推定)をするとE2のランクが上がる。

さらにラウンド数のみで安全性マージンを計っているがE2の特徴であるが、 NISTは「初期変換(pre-whitening)」「最終変換(post-whitening)」の安全性 マージンを加えていない。そのための処理コストを払っているE2に取っては不 利である。このE2の「初期変換」「最終変換」がどれだけのラウンド数に相当 するかというのは難しい問題だが前後で2ラウンドづつ合計4ラウンドの効果が あるものと思われる。それで安全性マージンを再計算してみると攻撃可能であ るという推定に対する安全性マージン率は77%、現時点で攻撃可能なラウンド 数に対する安全マージン率は128%となる。その半分の効果であっても各々55% と100%である。

しかも、一方ではMARSの32段の実体は「初期変換」「最終変換」が16段と評価 されているからであり、それが堂々と安全性マージンに加えられていている。 「初期変換」「最終変換」に関する正確な安全性の向上の議論はアカデミック な、この分野の専門家に任せるとするが、 安全性に関する部分でNISTの大 きな誤りと、評価の甘さにはE2を提案したNTTは大いに憤慨しているのでは ないだろうか。

    このことについて後にNTTのE2関係者に聞いてみたが、やはり憤慨していた。

さて安全マージンでははSerpentがトップとなる。MARSも良い成績を収めてい る。RC6はここでは最低の値を取るがRC6は高速な処理なので、今後さらにラウ ンドを加えて安全性マージン率を上げても、それでも他の暗号アルゴリズムよ りもアドバンテージがあることを頭の隅に残しておく必要がある。

ファイナリスト再考

ここでは独自の分析でファイナリストを考えてみる。ここで紹介した主要な評 価であるスピードと安全性マージンについてトップ3を列挙してみるとファイ ナリストと同じになる。ここで残念なのは、もしE2が正しく評価されていると 安全性マージンでRijndaelと入れ替わることだ。
スピードRC6 MARS Twofish
安全性マージン Serpent MARS Rijndael

また次に小さいクレームがついたCRYPTON、SAFER+を落して残りを残す(E2に関 してはNISTの評価が誤り)とすると

RC6 MARS Twofish Rijndael E2 Serpent CAST-256 DFC

が残る。ここから5つに選ぶとすると、まず速度が遅いCAST-256が落ちるだろ う。次に32bit CPU上で遅いDFCも落ちるだろう。速度と安全性ではRijndaelと E2のどちらが入ってもおかしくはないが、この2つを比較するならRijndaelの 方が処理速度が速く、かつE2のJava実装のような“マイナスとなる点"を持っ ていない。したがってE2はRijndaelには負けることになる。

結局は、ここでのファイナリスト再考でもNISTと同じになる。ただし、もしE2 のJava実装があんなに極端な間違いを犯さなければE2はファイナリストに残っ ていた可能性が高いと思われる。その時は(現時点では)RijndaelとE2を区別す る差がほとんどないので5つではなく、6つのファイナリスト、あるいはそれ以 上のファイナリストを選んだ可能性もあるだろう。

NISTのファイナリストを選んだ理由に関しては、色々と間違いや、なぜそうなっ たのか謎な点(謎のグループ化)などが数々あるが、結果的にはこのファイナリ ストに関しては大きなクレームはついてはいない。ただしsci.cryptの議論で E2が落ちたことに関してはTwofishの主任開発者であるBruce Schneierが残念 であるというコメントを出していた。

最後に

ガラス張りともいえるオープンプロセスにより標準化暗号を決めていこうとす る手法を取った米国政府に対しては最大級の称賛を贈りたい。

日本から提案されたNTTのE2はAESレースには負けたが暗号アルゴリズム自体は 世界でもトップクラスの極めて優秀な暗号アルゴリズムであることに変わりが ないことを強調しておきたい。 ただし厳しいことをいわせてもらえばNTTはこのAESというレースの目的を認識 していないように思われる。これはグローバルスタンダードを決めていくプロ セスなのだ。査読委員が集まり学術的に良い暗号を選ぶような場ではない。衆 人環視の中で行われている残酷な生存競争なのだ。

NTTからはグルーバルスタンダードとして生き残るための戦略的なビジョンが 見えてこなかった。たとえばE2をTwofishやSerpent(あるいはMISTY1のように) のようにフリーにするとか、あるいはE2の優位性を活発にプロモーションする とか、あるいはJavaでの失点をカバーするためのコードを改定するとか、生き のびるためにやるべきことは色々あったように思う。

最後に、余談ではあるがE2に関してはこんな記事がsci.cryptに流れていたこ とを附記しておこう。

> From: jgfunj@vgrknf.arg (wtshaw)
> Newsgroups: sci.crypt
> Subject: Re: E2
> Date: Tue, 17 Aug 1999 16:28:16 -0600
>
> In article <7pamrr$ljk$1@news.monmouth.com>, fwojcik@monmouth.com wrote:
> > Is anyone else disappointed that E2 was not chosen as an AES finalist?
> > 
>
> In the original presentation, don't know if she did Rome also, the
> presenter certainly won in the cuteness category. 

[1] E. Biham, A. Shamir, "Differential cryptanalysis of DES-like cryptosystems", Advances in Cryptology - Crypto '90.

[2] M. Matsui, "Linear cryptanalysis method for DES cipher", Advances in Cryptology - EuroCrypt '93.

[3] T. Shimoyama and T.Kaneko, "Quadratic Relation of S-box and Its Application to the Linear Atttack of Full Round DES", Advances in Cryptology - Crypto '98.

[4] M. Matsui, T. Tokita, "Cryptoanalysis of a Reduced Version of the Block Cipher E2", FSE '99.

[5] B.Schnieier, J. Kelsey et al.,"Performance comparison of the AES submissions", The Second AES conference.

[6] Alan Folmsbee, "AES Java technology comparisons", The Second AES conference.

おしまい

TOP