(57)【要約】  ＡＥＳ等のアルゴリズムにおける鍵拡大機能中に必要とされるメモリ空間を減らすための装置、方法、コンピュータプログラム。所定数のバイト単位を暗号文／平文に暗号化／復号化するためのブロックラウンドユニット（２１２）。鍵拡大モジュール（２１５）は、拡大鍵値を得るために通常（暗号化）機能および逆（復号化）機能の両方に関して鍵拡大を実行する。拡大鍵値の格納のために必要とされるメモリ（２０２）内のメモリ空間の数は、拡大鍵値の数の半分よりも多くなく、一般に、１４個の鍵においては、鍵値およびメモリ空間の数が等しい場合に対してアクセス時間を増大させることなく、７個のメモリ空間を必要とする。鍵拡大はラウンド鍵処理と同期して行なわれ、それにより、各鍵拡大毎に、ラウンド鍵が対応する鍵拡大機能と並行して処理される。
2007500376.tif 000002
【特許請求の範囲】
【請求項１】
暗号化／復号化のための装置であって、
所定数の拡大鍵値を与えるとともに、メモリを有する、暗号鍵のための鍵スケジュールユニットと、
前記鍵スケジュールユニットと通信を行なうとともに、平文／暗号文のブロックを最初の複数の縦列において所定数のバイト単位に変換する変換モジュールと、
前記所定数のバイト単位を暗号文／平文に暗号化／復号化するためのブロックラウンドユニットと、
拡大鍵値を得るために通常（暗号化）機能および逆（復号化）機能の両方に関して鍵拡大を実行する鍵拡大モジュールと、
を備え、
拡大鍵値の格納のために必要とされるメモリ内のメモリ空間の数は、拡大鍵値の数の半分よりも大きくない装置。
【請求項２】
等しい数の拡大鍵値およびメモリ空間の数に対してアクセス時間が増大することなく、拡大鍵値の前記所定数が１４に等しく、メモリ空間の前記数が７に等しい、請求項１に記載の装置。
【請求項３】
拡大鍵値の前記所定数が１２に等しく、メモリ空間の前記数が６に等しい、請求項１に記載の装置。
【請求項４】
拡大鍵値の前記所定数が１０に等しく、メモリ空間の前記数が５に等しい、請求項１に記載の装置。
【請求項５】
前記暗号鍵の鍵長さが２５６ビットである、請求項２に記載の装置。
【請求項６】
前記暗号鍵の鍵長さが１９２ビットである、請求項３に記載の装置。
【請求項７】
前記暗号鍵の鍵長さが１２８ビットである、請求項４に記載の装置。
【請求項８】
前記暗号鍵の鍵長さが２５６ビットよりも長い、請求項１に記載の装置。
【請求項９】
前記鍵値が拡大される速度は、前記ブロックラウンドユニットによるラウンド鍵処理と同期される、請求項１に記載の装置。
【請求項１０】
前記鍵拡大モジュールが１４個の鍵を拡大するための手段を有し、これにより、鍵１〜７が暗号化中に連続的に拡大されるとともに、これらの各拡大鍵値は、他の鍵が連続的に拡大される前に並行してラウンド鍵アルゴリズムを処理するために使用される、請求項１に記載の装置。
【請求項１１】
前記鍵拡大モジュールが１４個の鍵を拡大するための手段を有し、これにより、復号化中に鍵１４〜８がメモリ空間内において降位置順で拡大された後、鍵１〜７が昇位置順で拡大され、その後、鍵１４〜８が降位置順で再び拡大される、請求項１に記載の装置。
【請求項１２】
前記メモリは、前記鍵値を格納するための７個以下のメモリ空間を有し、鍵８が位置１から読み取られると、鍵７が拡大されて所定に位置に置かれ、また、鍵７〜１が昇位置順で読み取られ、ラウンド鍵アルゴリズムが各鍵拡大と並行に実行される、請求項１１に記載の装置。
【請求項１３】
鍵拡大機能中にメモリ要件を減少させるための方法であって、
（ａ）所定数の拡大鍵値を与えるとともに、メモリを有する、暗号鍵のための鍵スケジュールユニットを設けるステップと、
（ｂ）前記鍵スケジュールユニットと通信を行なうとともに、平文／暗号文のブロックを最初の複数の縦列において所定数のバイト単位に変換する変換モジュールを設けるステップと、
（ｃ）ラウンド鍵を処理して、前記所定数のバイト単位を暗号文／平文に暗号化／復号化するためのブロックラウンドユニットを設けるステップと、
（ｄ）拡大鍵値を得るために通常（暗号化）機能および逆（復号化）機能の両方に関して鍵拡大を実行するための鍵拡大モジュールを設けるステップと、
を含み、
ステップ（ｄ）において鍵値が拡大される速度は、ステップ（ｃ）におけるブロックラウンドユニットによるラウンド鍵処理と同期され、これにより、対応する鍵値のそれぞれが、処理される対応するラウンド鍵と並行して拡大され、
前記拡大鍵値の格納のために必要とされる前記メモリ内のメモリ空間の数は、前記拡大鍵値の数の半分よりも多くない方法。
【請求項１４】
等しい数の拡大鍵値およびメモリ空間に対してアクセス時間が増大することなく、前記メモリ内のメモリ空間の数が７に等しく、拡大鍵値の前記所定数が１４に等しい請求項１３に記載の方法。
【請求項１５】
ステップ（ｄ）で設けられた前記鍵拡大モジュールが１４個の鍵を拡大し、これにより、鍵１〜７が暗号化中に連続的に拡大されるとともに、これらの各拡大鍵値は、他の鍵が連続的に拡大される前に並行してラウンド鍵アルゴリズムを処理するために使用される、請求項１３に記載の方法。
【請求項１６】
ステップ（ｄ）で設けられた前記鍵拡大モジュールが１４個の鍵を拡大し、これにより、復号化中に鍵１４〜８がメモリ空間内において降位置順で拡大された後、鍵１〜７が昇位置順で拡大され、その後、鍵１４〜８が降位置順で再び拡大される、請求項１３に記載の方法。
【請求項１７】
前記メモリは、鍵値を格納するための７個以下のメモリ空間を有し、鍵８が位置１から読み取られると、鍵７が拡大されて所定に位置に置かれ、また、鍵７〜１が昇位置順で読み取られ、ラウンド鍵アルゴリズムが各鍵拡大と並行に実行される、請求項１３に記載の方法。
【請求項１８】
鍵拡大機能中にメモリ要件を減少させるためのコンピュータプログラムプロダクトであって、
（ａ）暗号化／復号化のうちのいずれか一方の間に鍵拡大を実行するための実行可能命令と、
（ｂ）ステップ（ａ）における鍵スケジュールユニットによる鍵拡大と並行にブロックラウンドユニットによりラウンド鍵を処理し、それにより、各拡大鍵毎に対応するラウンド鍵が同期して処理されるようにする実行可能命令と、
（ｃ）メモリ内の所定数のメモリ空間が拡大鍵値の数の半分よりも多くならないように拡大鍵値を格納するための実行可能命令と、
を含む実行可能命令を有するコンピュータ読み取り可能媒体を備えているコンピュータプログラムプロダクト。
【請求項１９】
鍵拡大のためのステップ（ａ）における実行可能命令が１４個の鍵を拡大し、これにより、鍵１〜７が暗号化中に連続的に拡大されるとともに、これらの各拡大鍵値は、他の鍵が連続的に拡大される前に並行してラウンド鍵アルゴリズムを処理するために使用される、請求項１８に記載のコンピュータプログラムプロダクト。
【請求項２０】
ステップ（ａ）で与えられた鍵拡大のための実行可能命令が１４個の鍵を拡大するための命令を与え、これにより、復号化中に鍵１４〜８がメモリ空間内において降位置順で拡大された後、鍵１〜７が昇位置順で拡大され、その後、鍵１４〜８が降位置順で再び拡大される、請求項１８に記載のコンピュータプログラムプロダクト。
【請求項２１】
ステップ（ａ）および（ｂ）における実行可能命令は、メモリ空間が鍵値を格納するための７個以下のメモリ空間を含み、鍵８が位置１から読み取られると、鍵７が拡大されて所定に位置に置かれ、また、鍵７〜１が昇位置順で読み取られ、ラウンド鍵アルゴリズムが各鍵拡大と並行に実行されることを含んでいる、請求項１８に記載のコンピュータプログラムプロダクト。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、暗号化を実行するための方法および装置に関する。特に、本発明は、高度暗号化規格（ＡＥＳ）において一組のラウンド鍵を生成するために鍵拡大アルゴリズムにより使用される暗号鍵に関する。
【背景技術】
【０００２】
スマートカード等のアイテムの使用の増大およびインターネット上での商取引の増大に伴って、データを暗号化および復号化する必要性が、いまだかつて現在ほど重要になってきたことはない。実際に、米国政府は、特に国立標準技術研究所（ＮＩＳＴ）を通じて、長年の間、ＤＥＳ（データ暗号化規格）等の暗号化規格を選択してきた。ＤＥＳは、１９７６年に遡って米国規格として選択されたものであり、その後、３つのＤＥＳが規格となった。近年、ＮＩＳＴは、米国の公的な暗号化規格になるであろう新たな規格（ＡＥＳ）を選択するために、複数のＡＥＳアルゴリズムを評価してきている。Ｊｏａｎ  ＤａｅｍｅｎおよびＶｉｎｃｅｎｔ  Ｒｉｊｍｅｎは、ＮＩＳＴによって承認されてきた暗号化アルゴリズムを提示し、Ｆｅｄｅｒａｌ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｐｒｏｃｅｓｓｉｎｇ  Ｓｔａｎｄａｒｄｓ  Ｐｕｂｌｉｃａｔｉｏｎ  Ｎｏ．１９７（以下、ＦＩＰＳ’１９７と称する）と題して２００１年１１月２６日に公表した。ＦＩＰＳ’１９７におけるこのアルゴリズムは、Ｒｉｊｎｄａｅｌアルゴリズムと称される。
【０００３】
ＡＥＳは、従来の５６ビット暗号化を性能、自由度、効率に関して向上させ、それにより、具現化するための更に容易な方法を与えるべく、１２８，１９２，２５６ビットの３つのシステムを使用する。
【０００４】
ＡＥＳアルゴリズムで処理するための基本的な単位はバイトである。内的には、ＡＥＳアルゴリズムの演算は、ＳＴＡＴＥと呼ばれる２次元のバイト配列で実行される。ＳＴＡＴＥは一般にバイトから成る４つの横列を有しており、各横列はＮｂバイトを含んでいる。ここで、Ｎｂはブロック長を３２で割ったものである。
【０００５】
暗号化は、データを暗号文と呼ばれる難解な形式に変換する。暗号文の復号化は、「平文」と称されるデータをその元の最初の形式に変換し直す。共通の専門技術用語では、平文を暗号文に変換する一連の変換を「暗号」と称する。これに対し、暗号文を平文に変換する一連の変換は「逆暗号」と称される。暗号および逆暗号の両方において、拡大鍵ルーチンによって使用される秘密暗号鍵である暗号鍵は、暗号および逆暗号ルーチンにおいてＳＴＡＴＥに適用される一連の値（ラウンド鍵と呼ばれる）を生成する。
【０００６】
ＡＥＳアルゴリズムにおける入力および出力はそれぞれ、連続する１２８ビット配列（０または１の値を持つ数字）から成る。これらの配列は、時として、ブロックと称され、また、それらが含んでいるビット数を長さと称する。
【０００７】
図１はＳＴＡＴＥ配列入出力の一例を示している。暗号および逆暗号の開始時には、図１に示されるように、バイトの入力配列（ｉｎ０〜ｉｎ１５）がＳＴＡＴＥにコピーされる。その後、このＳＴＡＴＥ配列上で暗号演算または逆暗号演算が行なわれた後、その最終的な値が出力バイトの配列ｏｕｔ０〜ｏｕｔ１５に対してコピーされる。図１に関しては、ＮＩＳＴによる「ＦＩＰＳ１９７」に開示されているように、暗号および逆暗号の開始時に、バイト配列ｉｎ０〜ｉｎ１５である入力が図示のようにＳＴＡＴＥ配列に対してコピーされる。その後、このＳＴＡＴＥ配列に関して暗号演算または逆暗号演算が行なわれた後、その最終的な値が出力にコピーされる。これは、ｏｕｔ０〜ｏｕｔ１５の範囲のバイト配列として示されている。２つの要素に関する多項式中の対応する指数における係数を「加える」ことにより、有限領域において２つの要素の加算が行なわれる。加算は、ブール排他的論理和（ＸＯＲ）演算（「ＦＩＰＳ’１９７」，ＮＩＳＴ，１０頁）を用いて行なわれる。２バイトを加算するための２進法例が以下に示されている。
【数１】
2007500376.tif 000003
【０００８】
暗号鍵は、一組のラウンド鍵を生成するために鍵拡大アルゴリズムによって使用される秘密暗号鍵であり、４つの横列とＮｋ個の縦列とを有するバイトの矩形配列として描くことができる（「ＦＩＰＳ’１９７」，ＮＩＳＴ，６頁）。
【０００９】
ラウンド鍵は、鍵スケジュールによって暗号鍵から得られる値である。鍵スケジュールは、２つの構成要素、すなわち、鍵拡大およびラウンド鍵選択（「Ｒｉｊｎｄａｅｌ暗号ブロック」，Ｄａｅｍｅｎ  ａｎｄ  Ｒｉｊｍｅｎ，１４頁）を含んでいる。ＡＥＳは、暗号鍵を利用するとともに鍵拡大ルーチンを実行することにより鍵スケジュールを生成するアルゴリズムを使用する。
【００１０】
ラウンド鍵は、暗号・逆暗号変換においてＳＴＡＴＥに対して適用される。ラウンド鍵の長さはＳＴＡＴＥのサイズに等しく、また、ラウンド鍵はＸＯＲ演算を使用してＳＴＡＴＥに加えられる。
【００１１】
ここで、我々は、鍵拡大をサポートするために必要なメモリのサイズ低減について考える。現在のティーチングは、３つの鍵長さ、すなわち、１２８，１９２，２５６ビットをサポートするために暗号鍵が拡大されるハードウェア実施を規定している。計算の数は、鍵ビットおよびブロックビットによって決まる。１２８長さの鍵の場合には、１０個の計算が必要である。１９２長さの鍵の場合には、１２個の計算が必要とされる。最も長い現在の鍵長さ（２５６）の場合には、１４個の計算が必要である。つまり、必要な鍵の最大数は１４個である。
【００１２】
当初のＡＥＳソフトウェア実施は、最大数の鍵（１４）用の格納装置を使用している。ハードウェアにおいて、この格納装置は、１４×１２８ビットの格納場所を必要とする。ＣＭＯＳ１８におけるこの機能の実施は、約１００００個のゲートを使用する。
【発明の開示】
【課題を解決するための手段】
【００１３】
したがって、ゲートサイズを減少させる方法を提供すると同時に、最大経路遅延をあまり大きく増大させず、それにより、高データ転送速度設計に関して従来周知のものよりも魅力的な小型回路を実現することが有益である。
【００１４】
本発明は、最大経路遅延に影響を与えることなく拡大鍵機能を処理するために必要なゲート量を減少させる方法を提供する。本発明の利点は、回路の量を減らすことによりサイズが低減し、それにより、回路が更に小型化されるとともに高データ転送速度設計において更に魅力的なものになるという点である。
【００１５】
本発明の一態様において、各鍵拡大は、暗号化および復号化の両方をサポートするために行なわれる。新たなアーキテクチャは、ラウンド鍵処理と同期される通常の鍵拡大および逆鍵拡大の両方を実施する回路を利用し、それにより、更に小さいメモリ領域を使用することができる。特定の実施形態において、メモリ空間は、アクセス時間を増大させることなく、従来の１４個から、１４個の拡大鍵に関してこれまで知られていなかった７個というメモリ空間数へと半減される。
【００１６】
本発明の前記特徴および他の特徴並びに利点は、添付図面と併せて以下の詳細な説明を参照することにより更に明らかとなる。
【発明を実施するための最良の形態】
【００１７】
以下の説明では、限定を目的とするのではなく解説を目的として、本発明の十分な理解を与えるべく、例えば特定のアーキテクチャ、インタフェース、技術等の特定の内容が示されている。しかしながら、当業者であれば分かるように、本発明は、これらの特定の内容から逸脱する他の実施形態において実施されても良い。また、明確にするべく、周知の装置、回路、方法の詳細な説明については省略し、本発明の説明が不必要な内容によって不明確とならないようにしている。
【００１８】
図２は、本発明の装置を設けることができる１つの方法を示している。当業者であれば分かるように、図示の物理的なレイアウトは説明の目的で与えられており、例えば、鍵拡大モジュールと鍵スケジューラとを組み合わせることができ、また、メモリを任意のモジュールまたは別個の領域の一部とすることができる。
【００１９】
鍵スケジュールユニット２０１は、鍵拡大（キー拡張）モジュール２１５によって拡大（拡張）される鍵値を有している。これらの値はメモリ２０２に格納することができる。変換ユニット２０８は、特定の所定数のラウンドにおいて平文／暗号文のうちの一方を暗号化／復号化し、また、ブロックラウンドユニット２１２は、鍵拡大ユニットが鍵拡大を行なう間にラウンド鍵処理を実行する。鍵拡大機能およびラウンド鍵処理は、これらの演算が同時に（多かれ少なかれ並行して）実行されるように、対応するそれぞれの鍵毎に同期されることが好ましい。
【００２０】
本発明においては、僅かな数のメモリ空間を用いて鍵拡大アルゴリズムを実施することにより、鍵が使用されるタイミングが重要な因子になる。例えば、暗号化モード中においては、処理が始まる前に１つの鍵を計算しなければならない。データがラウンド鍵アルゴリズムによって処理される間、第２の鍵を同時に計算することができる。１つの暗号化モードだけが必要とされた場合には、１つのメモリ空間で十分である。
【００２１】
復号化におけるタスクはやや困難である。これは、鍵１４が最初に使用されるからである。鍵１４は、他の１３個の鍵に基づいて計算しなければならない。ここでも、ラウンド鍵処理を用いて鍵を同時に計算するという同じ考え方を使用できる。鍵をメモリに書き込む順番が注意深く計画されれば、たった７個のメモリ空間と極僅かな更なる制御論理とを用いて暗号化および複合化の両方をサポートすることができる。
【００２２】
ラウンド鍵処理に関連して鍵が計算される速度も注意深く計画されなければならない。鍵計算およびラウンド鍵処理を同期化と同時に行なうことにより、本発明の利点が得られる。
【００２３】
２５６鍵長さ（キー長）は大部分のメモリを必要とするため、この長さは新たなメカニズムを示すために使用される。以下は、Ｒｉｊｎｄａｅｌ（Ｒｉｊｎｄａｅｌ−ａｌｇ−ｒｅｆ．ｃ  ｖｅｒｓｉｏｎ２．０，  Ｂａｒｒｅｔｏ  ａｎｄ  Ｒｉｊｍｅｎ）に係るＣコード表記において与えられる従来のアルゴリズムである。
Ｉｎｔ  ｒｉｊｎｄａｅｌＫｅｙＳｃｈｅｄ（ｗｏｒｄ９ｋ［４］［ＭＡＸＫＣ］，  ｉｎｔ  ｋｅｙＢｉｔｓ，  ｉｎｔ  ｂｌｏｃｋＢｉｔ，  ｗｏｒｄ８
Ｗ［ＭＡＸＲＯＵＮＤＳ＋１］［４］［ＭＡＸＡＢＣ］）｝
／＊Ｃａｌｃｕｌａｔｅ  ｔｈｅ  ｎｅｃｅｓｓａｒｙ  ｒｏｕｎｄ  ｋｅｙｓ
＊Ｔｈｅ  ｎｕｍｂｅｒ  ｏｆ  ｃａｌｃｕｌａｔｉｏｎｓ  ｄｅｐｅｎｄｓ  ｏｎ  ｋｅｙＢｉｔｓ  ａｎｄ  ｂｌｏｃｋＢｉｔｓ
＊／
ｉｎｔ  ＫＣ，  ＢＣ，  ＲＯＵＮＤＳ；
ｉｎｔ  Ｉ，  ｊ，  ｔ，  ｒｃｏｎｐｏｉｎｔｅｒ＝０；
Ｗｏｒｄ８  ｔｋ［４］［ＭＡＸＫＣ］
ｓｗｉｔｃｈ  （ｋｅｙＢｉｔｓ０｛
ｃａｓｅ  １２８  ：  ＫＣ＝４；ｂｒｅａｋ；
ｃａｓｅ  １９２  ：  ＫＣ＝６；ｂｒｅａｋ；
ｃａｓｅ  ２５６  ：  ＫＣ＝８；ｂｒｅａｋ；
ｄｅｆａｕｌｔ  ：  ｒｅｔｕｒｎ（−１）；
｝
ｓｗｉｔｃｈ  （ｂｌｏｃｋＢｉｔｓ）｛
ｃａｓｅ  １２８  ：  ＢＣ＝４；ｂｒｅａｋ；
ｃａｓｅ  １９２  ：  ＢＣ＝６；ｂｒｅａｋ；
ｃａｓｅ  ２５６  ：  ＢＣ＝８；ｂｒｅａｋ；
ｄｅｆａｕｌｔ  ：  ｒｅｔｕｒｎ（−２）；
｝
ｓｗｉｔｃｈ  （ＫｅｙＢｉｔｓ＞＝ｂｌｏｃｋＢｉｔｓ？  ｋｅｙＢｉｔｓ  ：  ｂｌｏｃｋｂｉｔｓ）｛
ｃａｓｅ  １２８  ：  ＲＯＵＮＤ＝１０；ｂｒｅａｋ；
ｃａｓｅ  １９２  ：  ＲＯＵＮＤ＝１２；ｂｒｅａｋ；
ｃａｓｅ  ２５６  ：  ＲＯＵＮＤ＝１４；ｂｒｅａｋ；
ｄｅｆａｕｌｔ  ：  ｒｅｔｕｒｎ（−３）；／＊ｔｈｉｓ  ｃａｎｎｏｔ  ｈａｐｐｅｎ＊／
｝
ｆｏｒ（ｊ＝０；  ｊ＜ＫＣ；  ｊ＋＋）
ｆｏｒ（ｉ＝０；  ｉ＜４；  ｉ＋＋）
ｔｋ［ｉ］［ｊ］＝１［ｉ］［ｊ］；
ｔ＝０；
／＊ｃｏｐｙ  ｖａｌｕｅｓ  ｉｎｔｏ  ｒｏｕｎｄ  ｋｅｙ  ａｒｒａｙ＊／
ｆｏｒ（ｊ＝０；（ｊ＜ＫＣ）＆＆（ｔ＜（ＲＯＵＮＤＳ＋１）＊ＢＣ）；  ｊ＋＋，  ｔ＋＋）
ｆｏｒ（Ｉ＝０；  ｊ＜４；  ｉ＋＋）Ｗ［ｔ／ＢＣ］［ｉ］［ｔ％ＢＣ］＝ｔｋ［ｉ］［ｊ］；
ｗｈｉｌｅ（ｔ＜ＲＯＵＮＤＳ＋１）＊ＢＣ）｛／＊ｗｈｉｌｅ  ｎｏｔ  ｅｎｏｕｇｈ  ｒｏｕｎｄ  ｋｅｙ  ｍａｔｅｒｉａｌ  ｃａｌｃｕｌａｔｅｄ＊／
／＊ｃａｌｃｕｌａｔｅ  ｎｅｗ  ｖａｌｕｅｓ＊／
ｆｏｒ（Ｉ＝０；  Ｉ＜４；  ｉ＋＋）
ｔｋ［ｉ］[０]＾＝Ｓ[ｔｋ（ｉ＋１）％４][ＫＣ−１]；
ｔｋ［０］［０］＾＝ｒｃｏｎ  ［ｒｃｏｎｐｏｉｎｔｅｒ＋＋］；
ｉｆ（ＫＣ！＝８）
ｆｏｒ（ｊ＝１；  ｊ＜ＫＣ；  ｊ＋＋）
ｆｏｒ（ｉ＝０；  ｉ＜４；  ｉ＋＋）ｔｋ［ｉ］［ｊ］＾＝ｔｋ［ｉ］［ｊ−１］；
ｅｌｓｅ｛
ｆｏｒ（ｊ＝１；  ｊ＜ＫＣ／２；  ｊ＋＋）
ｆｏｒ（ｉ＝０；  ｉ＜４；  ｉ＋＋）ｔｋ［ｉ］［ｊ］＾＝ｔｋ［ｉ］［ｊ−１］
ｆｏｒ（ｉ＝０；  ｉ＜４；  ｉ＋＋）ｔｋ［ｉ］［ＫＣ／２］＾＝Ｓ［ｔｋ  ［ｉ］  ［ＫＣ／２−１］］；
ｆｏｒ（ｊ＝ＫＣ／２  ＋１；  ｊ＜ＫＣ；  ｊ＋＋）
ｆｏｒ（ｉ＝０；  ｉ＜４；  ｉ＋＋）ｔｋ［ｉ］［ｊ］＾＝ｔｋ［ｉ］［ｊ−１］；
｝
／＊ｃｏｐｙ  ｖａｌｕｅｓ  ｉｎｔｏ  ｒｏｕｎｄ  ｋｅｙ  ａｒｒａｙ＊／
ｆｏｒ（ｊ＝０；  （ｊ＜ＫＣ）＆＆（ｔ＜（ＲＯＵＮＤＳ＋１）＊ＢＣ）；  ｊ＋＋，  ｔ＋＋）
ｆｏｒ（ｉ＝０；  Ｉ＜４；  ｉ＋＋）Ｗ［ｔ／ＢＣ］［ｉ］［ｔ％ＢＣ］＝ｔｋ［ｉ］［ｊ］；
｝
ｒｅｔｕｒｎ  ０；
｝
【００２４】
ハードウェア実施においては、前記コード（ｃａｓｅ２５６；  ＲＯＵＮＤＳ＝１４；  ｂｒｅａｋ；）を実施するために、１４個の鍵における最大量のメモリが割り当てられなければならない。
【００２５】
また、この従来の拡大アルゴリズムは、ラウンド鍵の処理が始まり且つ並行作業を許容しない前に行なわれる。
【００２６】
以上とは異なり、本発明は、ラウンド鍵処理と同期される、通常の鍵拡大および逆の鍵拡大の両方を実施する回路を使用する。
【００２７】
暗号化（通常）拡大を考えると、与えられた例は、それが大部分のメモリのロケーションを必要とするため、鍵長さ（キー長）２５６である。他の２つのケース（１２８および１９２の鍵長さ）も拡大された鍵が殆ど不要であることから機能するのが分かる。また、２５６を越える鍵長さがこれまでに使用されている場合には、必要なメモリを減らすのに本発明が有効であることも理論的に分かる。
【００２８】
本発明の一態様において、鍵の拡大とラウンド（丸めること）とを並行に行なうためのアルゴリズムは以下の通りである。
Ｅｘｐａｎｄ−Ｋｅｙ Ｎｕｍｂｅｒ＝１４
Ｆｏｒ  ｋ＝１  ｔｏ  Ｅｘｐａｎｄ Ｋｅｙ Ｎｕｍｂｅｒ
｛
Ｉｆ（ｋ＜８）ｎ＝ｋ  ｅｌｓｅ  ｎ＝ｋ−７
Ｅｘｐａｎｄ  ｋｅｙ  ｋ  ａｎｄ  ｓｔｏｒｅ  ｔｏ  ｌｏｃａｔｉｏｎ  ｎ
Ｒｅａｄ  ｌｏｃａｔｉｏｎ  ｎ  ａｎｄ  ｄｏ  Ｒｏｕｎｄ  Ｋｅｙ  ａｌｇｏｒｉｔｈｍ，  ｅｘｐａｎｄ  ｋｅｙ  ｋ  ａｎｄ  ｓｔｏｒｅ  ｔｏ  ｌｏｃａｔｉｏｎ  ｎ＋１
｝
【００２９】
復号化（逆）拡大においては、１４個の全ての鍵を最初に計算しなければならない。最初の７個の鍵における計算は、降順で行なわれた後、投げ捨てられる。次の７個の鍵は昇位置順で拡大される。最後の７個の鍵が降順で読み取られると、最初の７個が再び降順で拡大される。鍵８が位置１から読み取られると、鍵７が拡大されて位置１に置かれる。その後、鍵７〜１が昇位置順で読み取られる。アルゴリズムは以下の通りである。
Ｅｘｐａｎｄ Ｋｅｙ Ｎｕｍｂｅｒ＝１４
Ｆｏｒ  ｋ＝１  ｔｏ  Ｅｘｐａｎｄ Ｋｅｙ Ｎｕｍｂｅｒ
｛
Ｉｆ（ｋ＜８）ｎ＝８−ｋ  ｅｌｓｅ  ｎ＝ｋ−７
Ｅｘｐａｎｄ  ｋｅｙ  ｋ  ａｎｄ  ｓｔｏｒｅ  ｔｏ  ｌｏｃａｔｉｏｎ  ｎ
｝
Ｆｏｒ  ｋ＝Ｅｘｐａｎｄ Ｋｅｙ Ｎｕｍｂｅｒ  ｔｏ  １
｛
Ｉｆ（ｋ＜８）ｎ＝８−ｋ  ｅｌｓｅ  ｎ＝ｋ−７
Ｒｅａｄ  ｌｏｃａｔｉｏｎ  ｎ  ａｎｄ  ｄｏ  Ｒｏｕｎｄ  Ｋｅｙ  ａｌｇｏｒｉｔｈｍ，  ｅｘｐａｎｄ  ｋｅｙ  ８−ｎ  ａｎｄ  ｓｔｏｒｅ  ｔｏ  ｌｏｃａｔｉｏｎ  ｎ
｝
【００３０】
最後に、図３は、本発明を実行できる１つの方法を説明する方法ステップを示している。ステップ３０５においては、暗号鍵のための鍵スケジュールユニット２０１が与えられる。前記鍵スケジュールユニット２０１は、所定数の拡大鍵値を与えるとともに、メモリ２０２を有している。
【００３１】
ステップ３１０は、変換モジュール２０８が鍵スケジュールユニット２０１と通信することを含んでいる。変換モジュールは、平文／暗号文のブロックを、最初の複数の縦列において所定数のバイト単位に変換する。
【００３２】
ステップ３１５は、所定数のバイト単位を暗号文／平文に暗号化／復号化するために、ブロックラウンドユニット２１２がラウンド鍵を処理することを含んでおり、また、
ステップ３２０は、拡大鍵値を得るために通常（暗号化）機能および逆（復号化）機能の両方に関して鍵拡大モジュール２１５が鍵拡大を実行することを含んでいる。
【００３３】
ステップ３２０において鍵値が拡大される速度は、ステップ３１５におけるブロックラウンドユニット２３５によるラウンド鍵処理と同期され、これにより、対応する鍵値のそれぞれが、処理される対応するラウンド鍵と並行して拡大される。
【００３４】
したがって、拡大鍵値の格納のために必要とされるメモリ２０２内のメモリ空間の数は、拡大鍵値の数の半分よりも多くない。
【００３５】
２つの方法で実施されたＡＥＳ案（ＮＩＳＴ，２００１年１１月２６日）により提案されたデザイン；１４個のメモリ空間を用いた１２８，１９２，２５６鍵長さ、および、メモリ空間の半分を用いた第２のデザインを検討することにより、また、ラウンド鍵処理に関して注意深い再計算を使用することにより、新たなアルゴリズムが必要な空間を１／２だけ減らすことが本発明により明らかになった。
【００３６】
当業者であれば分かるように、本発明の思想または添付の請求項の範囲から逸脱しない様々な変形例を形成することができる。例えば、使用される共通論理のビット数、装置のモジュールおよびサブモジュールのレイアウト、変換されるデータのブロックの数、入出力モジュールの全てを必要に応じて変更することができる。本発明は、セキュリティネットワーキングプロセッサ、安全なキーボード装置、磁気カードリーダ装置、スマートカードリーダ装置、８０２．１１等の無線通信アプリケーション装置と共に使用することができるため、データの受信または出力を、共通の回路内に含ませることができ、あるいは、ＲＦ、光ファイバ、マイクロ波等にわたって送信することができる。そのような場合、様々なタイプの送信からのプロトコル変換と共に、送受信能力が含められる。また、実施例は８バイト（１２８ビット）を示しているが、この量は、必要に応じて増大または減少させることができ、および／または、ＡＥＳプロトコルにおいては変化する。なお、「平文」および「暗号文」等の用語は専門用語であり、暗号化／復号化は、図面、写真、イラスト、略図を包含することができ、音声、ビデオ、および／または、マルチメディアデータを含むことができる。
【００３７】
例えば、鍵拡大モジュールは、図示するために、鍵スケジューラから分離される別個のユニットとして示されており、また、鍵スケジューラ内に示されるメモリが共通のメモリであっても良く或いは配列されても良く、および／または、全ての構成要素が共通の回路カード上に配置されても良い。１２８，１９２，２５６長さの鍵ブロックが一例として使用されたが、本発明の思想および添付の請求項の範囲から逸脱することなく、これらよりも長いまたは短い任意の長さの鍵ブロックを使用することができる。
【図面の簡単な説明】
【００３８】
【図１】ＳＴＡＴＥ配列およびその入出力バイトを示している。
【図２】本発明に係る装置を配置できる１つの方法を示している。
【図３】本発明に係る方法の概要を示すフローチャートである。
【符号の説明】
【００３９】
２０１  鍵スケジュールユニット
２０２  メモリ
２０８  変換ユニット
２１２  ブロックラウンドユニット
２１５  鍵拡大（キー拡張）モジュール
【図１】
2007500376.tif 000004
【図２】
2007500376.tif 000005
【図３】
2007500376.tif 000006
【国際調査報告】
2007500376.tif 000007
2007500376.tif 000008
2007500376.tif 000009