暗号

暗号の話（６）－ DES の後継

やまだ — Tue, 18 Dec 2007 03:56:00 GMT

あー、お久しぶりです。ほぼ一カ月ぶりですね。前回の暗号の話からすると、さらに。

まあ、平日は会社から真夜中に帰って疲れきってて、休日は文字通りひっくり返ってましたので、いつエントリ書くんだ、という状態だったわけですが……。
まあ、そういうことをいつまでも、ぐだぐだぐだぐだぐだぐだぐだぐだぐだぐだぐだぐだぐだぐだぐだぐだ言ってても、しかたありませんので、今回、軽めにさくっとあげてみます。

では、DESの続きです。共通鍵暗号の話をまず終わらせてしまいましょう。
＃今回だけ読むとよくわからんですね(^^;

しかし、コンピュータの高速化等の要因により、DESだけでは暗号として非力とみなされるようになってきました。
そこで、DES を若干改良した暗号方式として3DESが用いられるようになってきました。しかし、この3DESは暗号アルゴリズムとしては、目新しいものではありません。DESをそのまま拡張したものとなっています。
3DESでは、DESに比べ鍵の長さは2倍の128ビットとなります。この鍵の前半、後半でそれぞれDESによる暗号化・復号を繰り返します。
3DESは独立した暗号アルゴリズムというより、DESを利用したマクロ定義といった方が近いかもしれません。
また、2DES でなくていきなり3DESになっているのは、2DESだと単なるDESよりも安全性が低くなることが立証されているから、ということだそうです。

しかし、いつまでも3DESというのも、という風潮の中、DESに変わる暗号の標準を定めようという動きが生まれました。それがAESです。で、この時点でAESの暗号アルゴリズムは決まっていませんでした。
次期標準AESたるに相応しい暗号アルゴリズム、ということで公募がかかり、最終的に採択されたのがRijndael（カタカナで書くと「ラインダール」）暗号となります。

では、共通鍵(Common Key)暗号方式についてはここまでとし、暗号と一緒に用いられることの多いハッシュについて述べ、その次に公開鍵暗号方式に入ることといたしましょう。

＃AESをこんなにさくっと流して良いのか、ってな話もありますが。

ここまでのデータは、こちら。

暗号の話（５）－ DES です

やまだ — Mon, 05 Nov 2007 00:51:00 GMT

＃随分間があいてしまいました。覚えている人がどれだけいるかは別として続けます。
＃あ、10月のページビューは5878件でした。他の人と比べたらどうということはない数字かもしれないけれど、わたし的には月間最高記録だったのでよしとしましょう。その代わり、最低記録を更新した日もあったことだし(T^T)

ですDES。もとい、DESです。

では、共通鍵暗号（対称鍵暗号とも言うらしい）の一つとしてDESを紹介します。まず、DESの特徴です。

ここではアルゴリズム自体の説明は省略します。どこかでフローチャート見ればそれ以上特に説明はいらないと思いますし、それ以上の説明もできません。

共通鍵暗号の性格として、DESでは暗号化の鍵と復号の鍵が同一になっています。暗号化した鍵でないと復号することはできません。このときに利用される鍵は、64ビットの長さが必要です。ただし、8ビットはパリティとして使われるので、実質は56ビットしか利用されてはおりません。

また、DESはブロック暗号と呼ばれる種類の暗号でもあります。ブロック暗号とは一定の単位で暗号化を行うものです。DESでは鍵の長さと同じ64ビット単位で暗号化を行います。この変換の際には、S BOX と呼ばれるアルゴリズム内部で持つ変換テーブルを利用します。このテーブルを利用して、暗号化時にはデータを入れ替えるわけですが、当然ながら復号時にはその逆の形で入れ替えを行うことになります。
つまり、暗号化と復号のロジック自体が対称となります。ですので、DESの「復号」を利用して暗号化を行ったものを、「暗号化」で復号することもできるわけですね。

では、DESは 64ビット以上のデータを暗号化できないのか、というと、そんなことはありません。繰り返して使えば良い訳ですね。
しかし、その繰り返し方にもいろいろあります。ここでは、そのうち代表的な二つの例を示します。

ECB モードは、その名のとおり単純に対応表を引いていく形式です。
64ビット単位で暗号化・復号を順に行っていきます。64ビット単位で独立に暗号化・復号を行いますので、64ビットのブロック単位であれば、どの部分からでも暗号化・復号は可能です。
また、DESアルゴリズム自体には乱数要素は存在しませんので、同じ平文の部位に対しては同じ暗号文が得られることになります。このため、同様のフレーズの繰り返しがある平文では差分解読に対する強度はあまり強くないと考えられます。

CBCモードは、上記の点から、もう少し解読を困難にしようとするものです。前ブロックの暗号化（復号）の結果を次ブロックの暗号化（復号）を行うための入力として引き継ぎます。
このため、平文上で同じフレーズであったとしても、その前までのブロックでの暗号化の結果によって暗号文はまったく異なったものとなります。
これだけでは、先頭ブロックは、その前のブロックが存在しませんので常に同じ結果になります。そのため、CBCモードでは初期ベクトル(IV)というもので、擬似的に前ブロックまでの暗号化結果を指定できるようになっています。
復号の際は、この逆で、前のブロックまでの影響を排除しながら復号を行っていくこととなります。このため、データの途中からの復号ということができません。暗号化データが途中で壊れていると、そこから先は復号が不可能となります。
これにより、同じ平文を元にしても暗号文が異なりますので、差分による解読もより困難になるというわけです。

では、DES で強度的に十分なのか、というと現在ではそうもいえなくなってきています。
次回はさらっと Triple DES の話と、AES というものがあるよ、という話にしたいと思います。
＃ AES のアルゴリズム解説なんて、間違っても期待しないように。

ここまでのデータは、~~こちら~~最新エントリにて。

暗号の話（４）－ Alice と Bob の秘密の話、そして Carol が興味津々

やまだ — Wed, 17 Oct 2007 00:14:00 GMT

＃風邪引いて寝込みながら、こんなことをやっている自分に疑問を持たないでもなかったりしますが、そんなこたー置いといて。

では、そろそろ暗号の使われ方の話でも。

＃忘れた頃にやってくる？

と、そういうわけで共通鍵暗号方式の話です。（どーゆーわけだ？）

英文を直訳すると秘密鍵暗号とでもよぶべきところですが、ここでは共通鍵暗号と呼ぶことにします。後で出てくるprivate keyと紛らわしくなるからです。

共通鍵暗号とは、ざっとこの図に示したような方式です。一般的な暗号のイメージ通りですね。

暗号の世界で登場する人は順に Alice、Bob、Carol、Dave、Ellen と相場が決まっているようなので、慣習に倣ってみました。まぁ、名前と絵が合ってないようにも思えますが、気にしないように（笑）。

Alice は Bob に対して、他の人には秘密の連絡をしたかったとします。このために Alice は連絡内容を記した書面を暗号化します。この書面は Bob に渡されるまでは暗号化されています。

ですので、郵便配達人を装った Carol がそれを覗き見たとしても、その内容を知ることはできません。復号に利用するための鍵は、Alice と Bob しか持っていないのですから。

暗号化された書面を受け取った Bob は、Alice から事前に受け取っていた鍵を利用して書面の復号を行います。これにより、Alice と Bob は秘密を共有することができるようになる、というわけです。

以上から、共通鍵暗号方式の特徴をざっと整理してみます。

これは、暗号化に用いる鍵と復号に用いる鍵が共通、ということで、シンプルに実現が可能な方式です。そのため比較的高速な処理が可能になっています（何に比べて、という話は後述します）。

また、当たり前ですが、鍵を持っていない第三者に対しては、情報は秘匿されます。

それに対し、課題としては鍵の管理が挙げられます。Alice と Bob が鍵までも人を介してやりとりしたとすると、そこで鍵が漏れてしまうかもしれません。そうすると、以降、すべての情報が Carol に筒抜けになってしまうリスクがあります。

ですので、基本的に郵便を利用したやりとりをする場合でも、鍵だけは直接対面して手渡しなどの運用をする必要があるわけです。

さらに問題が複雑になるのは、三者以上で情報を共有する場合です。

Alice と Bob の秘密のネットワークに Dave が加わったとします。そうすると、Dave とも鍵を共有しなければなりません。ここで、Alice と Bob がどれだけ厳密に鍵の管理を行ったとしても、Dave がうっかり Carol に鍵を漏らしたりすることが考えられます。そうすると、Carol が Alice から Bob に宛てた暗号文を読んだり、Bob を装って Alice に暗号文で書面を送ったりすることも可能になります。

ですので、共通鍵暗号は基本は１対１で使用すべきものであり、対象を広げると信頼性は急激に低下することとなります。
では、どうすればよいか、という話ですが、その前にこの共通鍵暗号の代表である DES について触れてみたいと思います。

ここまでのPowerPointデータは~~こちら~~最新エントリです。
では、次回はDESです、ということで。

＃さぁて、このペースでいつ終わるんだろうかなぁ。

暗号の話（３）－始まったばかりで、なんで解読の話してんのさ？

やまだ — Mon, 08 Oct 2007 20:46:00 GMT

つーことで。　＃でも、さぁ暗号だっ、ていっていきなり群論の話とかされるよりは良かない？

＃あぁ、そーいえば 9 月のアクセス総数は 4,272 だったですよ。さらに落ち込んでますなぁ……。
＃と、私まで落ち込んでもしかたないので、まぁぼちぼちといきますか。

閑話休題。

で、私みたいな素人は思うわけですよ。

AES とかなんだかよくわかんない暗号方式ならべなくたって、換字レベルで問題ないんじゃないの？単純にスライドさせてるだけならともかく、置き換える文字をシャッフルした対応表があれば誰にもわかんねんじゃね？

って。

今回は、いやいやそれじゃ足りませんって、という話です。

で、まず解読手法についてなんですが、

パスワード総当り方式っ！
ソーシャルエンジニアリングっ！

とかってのは、対象外とします。

そもそも私の知っている範囲では「暗号」自体には「パスワード」の管理は含まれていないし、パスワード入力中の手元を覗き込まれたらどんな強固な暗号方式でも意味ないですわなぁ。

＃あ、パスワードチェックについてはそのうち書くかも。

では、今回の本題（前フリが長いって）。

＃わー、文字がいっぱい……ってそんな話じゃないっ！

実は先に示した例を簡単に使っただけでは、解読は比較的容易なのです。

まず一つ目は、文字頻度を分析する方法です。これは、単純な換字の暗号化に対して有効な方法です。

単純な暗号文の例で説明してみます。ここに挙げたのは、短文を３つほど並べた例です。簡略化のために句読点や空白は削除しており、大文字小文字の区別はしておりません。

で、この暗号文だけでも、文字の使われ方に偏りがあることがわかります。

ここで、元の平文が英文であることがわかっているとしますと、文字の使用頻度を元にした解析が可能です。普通の英文で考えると子音に比べ母音の使用頻度が高いはず。そう考えると、かなりの確率で対応する文字を予想することができます。

ある程度予測がつくと、穴埋めパズル的に前後を埋めていける、というわけです。

＃この解読方法そのままのネタが使われた有名な推理小説があったりします。

方法の二つ目としては、差分を基にした解読、というのがあります。

同じ暗号アルゴリズムを使用した暗号文を複数入手した場合、その暗号を見比べてみる（差分をとる）という方法が使えます。

示した例ではすべての文字が一定幅でずれています。個々の例で解読する努力をしなくとも、これだけでシーザー暗号であることがわかってしまいます。

同じ平文を基にした暗号文を複数入手することなどあまりないとはいえますが、メール等では「お世話になっております。」などの定型文が含まれていることはよくあります。その部分だけ比較すると解読のきっかけとなりえます。

シーザー暗号に限らなくとも、差分をとることでその暗号アルゴリズムを癖をみつけ、それが解読につながることがあるそうです。

以上より、単純な換字や転置では結構簡単に解読されてしまいます。ですので、これらを組み合わせ、より複雑な形でいろいろなアルゴリズムが提案されたり使用されたりしているわけです。

暗号は解読が難しければよいというものではありません。その性格から、CPUとメモリ容量には負荷がかかります。実時間で暗号化・復号ができないようでは実用に耐えません。

ですので、最適な暗号方式といっても一意に決定できるようなものではなく、使用できるＨＷや利用される局面によって変わることになります。

ここまでの PowerPoint データは~~こちらです~~最新エントリにて。

では、次回は共通鍵暗号方式についてです。

＃英語の直訳だと secret key=秘密鍵ですが、後々 private key と混乱するのであえて共通鍵と書いています。

暗号の話をしてみんとぞ思ふ（２）－序論：暗号とは？

やまだ — Thu, 04 Oct 2007 03:23:00 GMT

みんな来ない？僕も行くよー（ＴーＴ）
明後日だよー。

＃パクリもたいがいにしろって話ですね。はい、すみません。

まずは何かしら始めてみないと、ということで軽いネタフリから。というかいきなりそんなに進まねーよorz
＃あ、繰り返しますが、専門ではないので「違ってるよ！」という向きには逆にご指導いただけると幸いです。

では、ざっと暗号とは何かについて整理してみましょう。

暗号の元になる生のデータを一般に「平文（ひらぶん）」と呼ぶようです。この辺は Plain Text の直訳っぽいですね。
一方、解読を困難にした方のデータを「暗号文」と。「文」じゃないだろうって話もありますが、この辺は歴史的経緯によるものかもしれません(コメント参照)。
で、平文を暗号文に置き換えることを、「暗号に変える」ということで「暗号化」と呼びます。

その逆で暗号文を平文に「戻す」ことを「復号」と呼びます。復号というものに変えるわけではないので「復号化」とは呼びません。

同じ鍵で暗号化しても暗号アルゴリズムが違えば、まったく異なるデータができあがりますし、暗号アルゴリズムが同じでも鍵が違えばやはり異なるデータができあがります。
暗号アルゴリズムと鍵のペアで、暗号化・復号の処理は決定される、といえます。

データ圧縮は、鍵のない暗号化といえるかもしれません。

基本的な暗号の原理として２つのパターンが考えられます。
＃さあ、この辺からだんだん独断が入ってきましたよー。

「換字」は単にデータの置き換えです。例では、３文字分後ろにずらした文字で置き換えてます。復号時には、３文字分前にずらした文字で入れ替えればよいわけですね。別に固定幅でずらすんでなくても、一定周期でずらし幅を変えたり暗号表を利用したりしてもよいわけです。

「転置」はデータの順番自体を入れ替えるものです。例では、全データを逆順に並べ替えています。もう一度同じ処理を行うと元に戻りますね。数文字単位でブロックに分け、それごとに規則性を持たせた入れ替えを行う、というのでもよいですね。

で、暗号は、基本的にこの二つの組み合わせからなるわけです（……本当か？）

次回はこの性格から、暗号の特徴と解読の容易性について簡単に騙ってみたいと思います。

＃このペースではいつになったら終わるんだろ……。ストックなしの状態からはじめるもんじゃないなぁ。でも、ストック作ってからと思うと決して進まない罠。

あ、~~ここまでの~~データは~~こちら~~最新エントリからどうぞ。

暗号の話をしてみんとぞ思ふ（１）

やまだ — Sun, 30 Sep 2007 22:34:00 GMT

♪みっくみくにしてやんよー、ってちょっと壊れ気味の（っていうか、壊れきっている）やまだです。

ダッチさんのところで「空文字を暗号化すると・・・どうなる？」とか、なおこ(・∀・)さんのところで「MD5 の実装について調べてみた」とか読んでいるうちに、ふつふつと湧き上がってくるものが……。
これはオブ熱ならぬ暗号熱か、ということで勝手にひとり勉強会を立ち上げようかな、と。どうせなら、この際ある程度まとめてみようかな、と思ったり。

で、こんな感じで資料を書き始めてみました。いーのか、勝手にこのテンプレート利用して。
＃やめとけ、と、ストップかけるなら今のうちですよー。　＞　自分も含めて

あ、別に専門家ってわけでもないので、その辺は期待しないように。
というか、ちゃんと知りたい人はその辺の本を読むなり、検索なりかけた方が早いと思わないでもなかったり。
まぁ、ついでに誰かの役に立てばよいのかな、と。まぁ、単なる自己満足なんですが。

とりあえず今回は目次案まで。

ってな感じでどうでしょう。あ、感覚ベースであまり硬いものにするつもりはないです。
リクエストがあっても応えられるかどうかはわかりませんが、まぁ、ぼちぼちとやってみようかと。

真面目な話、暗号の専門家はいきなり高度な話をする傾向があるので、会話そのものが暗号化されている感があるんですよねー。
実際に、そういう人と他の技術者との通訳みたいなことをする必要があったりするので。

一般人の目線からちょっと騙ってみようかな、と。
そーゆーわけですので、正確さは後回しということで。
＃「いやいや、そーじゃないぞ」という場合には差し替え原稿をいただければ幸いです。

んでは。

＃次はいつになるかなぁ……。

暗号

暗号の話（６） － DES の後継

暗号の話（５） － DES です

暗号の話（４） － Alice と Bob の秘密の話、そして Carol が興味津々