人生を豊かにするための暗号技術の話 - ネクストスケープ 2014/04/24 パワーランチ資料

株式会社ネクストスケープ御中
パワーランチ：
人生を豊かにするための暗号技術の話
2014.04.24
株式会社ネクストスケープ

パワーランチ：人生を豊かにするための暗号技術の話
コンピュータにおける暗号化とは
Last Updated: Thursday, April 24, 2014
___ _________ ___ 2www.nextscape.net
コンピュータにおける暗号化とは…
コンピュータが扱えるのは結局はビット列だけ。
平文： 01001101 01110101 (平文は「ひらぶん」と読みます)
に対して、ある暗号アルゴリズムを使って、
鍵：11010100 11100011
で暗号化すると、
暗号文： 11011100 11111101
になる。同じ鍵で復号すると、平文に戻る、ということ。
よって、どんなにすぐれた暗号アルゴリズムであっても、総当り攻撃 (ブ
ルートフォース) で全ての鍵を試すような攻撃は可能。むしろ、総当たり
攻撃しか解析手法がない暗号アルゴリズムが一番優秀。
適当に決めた鍵で偶然復号できる可能性はゼロではないが、現実的には起
こりえないので、実際に世の中で使われている。

共通鍵暗号方式
共通鍵暗号方式とは
鍵がひとつ。暗号化・復号いずれも同じ鍵を使う。
例： zip アーカイブ+暗号化して、先方にメールで
zipファイルとパスワードを送る

共通鍵暗号方式の例
共通鍵暗号方式の例：
DES：鍵長56bit、ブロック長64bit
3DES：鍵長168bit/112bit/56bit、ブロック長64bit
AES：鍵長192bit/168bit/112bit、ブロック長128bit

DES
DES：鍵長56bit、ブロック長64bit
1974年、米NIST（国立標準技術研究所）が暗号アルゴリズムを公募。
IBM の暗号が採用され、1976年に連邦規格として承認。
アルゴリズムは公開するが、鍵は秘密にすることでセキュリティを守ると
いう考え方は非常に革新的であった。
それ以前は、アルゴリズムは国家機密だった。例
えばエニグマ。
第二次世界大戦でドイツが使用していた暗号機器
で、連合国側が解読に成功したが、ドイツは終戦
まで解読されていることを知らなかった (暗号ア
ルゴリズムが適切かどうか判断できないとこうな
る) エニグマの写真
(Wikipediaより)

鍵長・ブロック長
鍵長56bit の意味：
鍵は56bit 固定。ASCII 文字を7bitとすると、最大8文字ということ。
ブロック長 64bit の意味：
暗号化の対象とするデータ長は 64bit 固定。128bit でも 72bit
でも 56bit でもダメ。
→ では、長い文章の暗号化はどうするのか?

暗号利用モード
暗号利用モード：
ブロック長より長いデータを暗号化するための仕組み。
疑問：
「DES ブロック長 64bit で、データが192bit なら、64bit ごとに分割して、3
回繰り返したらいいんでは?」
→ そうすると、入力と鍵が同じであれば、必ず同じ結果が得られてしまう。
例：AAAA BBBB AAAA → XXXX YYYY XXXX
→ 暗号文の前半と後半が同じということは、平文の前半と後半も同じ、という
ヒントを与えてしまうのはまずいｓ。
なので、1ブロックを暗号化した結果を、次のブロックの入力の一部として利用
する方法が考案された。それが暗号利用モード。CBC・OFB・CFB とかいろい
ろあるが、CBC を使っておけばOK (前述の分割して単純に暗号化するってのは
ECB と呼ぶ。これは一番使ってはダメなモード)。

初期化ベクトル
初期化ベクトル (初期化ベクタ・Initial Vector・IV・iv とも言う)：
暗号利用モードの最初のブロックに初期値として与えるもの。鍵ではない。秘
密にしなくていいが、同じ暗号文を何度も送受信する場合は、繰り返し使うの
はよろしくない。
相手に伝える方法は?
→ 暗号データの先頭にくっつけて送ってもいい (iv は誰でも読めてよい) し、
同じデータを二度と再送しないのであれば、あらかじめ iv=0x218b9a0e など
と合意しておいてもいい。
↓こんなイメージ

パディング
「ブロック長より長いデータの場合はわかったけど、では短い場合は? “a” の
1バイトを送りたいときはどうする?」
→ パディングすればよい。
A → A 07 07 07 07 07 07 07
A B → A B 06 06 06 06 06 06
A B C → A B C 06 06 06 06 06
A B C D → A B C D 04 04 04 04
A B C D E → A B C D E 03 03 03
A B C D E F → A B C D E F 02 02
A B C D E F G → A B C D E F G 01
などと、長さをブロック長に揃えてから暗号化する (この例ではブロック長＝
64bit)。
復号した後は、データの末尾を見ればパディング部分の長さがわかるので、そ
の部分を削ればよい。

パディング
「64bit ぴったりのときはパディングどうなるの?」
→ 実装による。「08 08 08 08 08 08 08 08」をつけるものもあれば、何もつ
けないものもある。ここが異なると当然ながら復号できないので、あらかじめ
合意しておく必要がある。
パディングにはいくつかやり方がある。PKCS#7を使っておけばいいのでは。
・PKCS#7 (PKCS#5) ≒ RFC2315
・ISO10126
・ANSI X.923
・ゼロパディング

暗号化したいときは
「共通鍵暗号方式で暗号化する」となった場合、
・暗号アルゴリズム
・鍵長
・初期化ベクトル(iv)
・鍵
・暗号利用モード
・パディング方式
を決めること。

暗号化のサンプルソース
AesCryptoServiceProvider aes = new AesCryptoServiceProvider();
aes.BlockSize = 128; // ブロックサイズ (AESのブロックサイズは 128bit 固定なので128)
aes.KeySize = 128; // 鍵長。ここは 168 でも 192 でもよい。
aes.IV = Encoding.UTF8.GetBytes(@"!QAZ2WSX#EDC4RFV“); // IV
// ↓鍵。128bitを選んだので128bitにする。
aes.Key = Encoding.UTF8.GetBytes(@“5TGB&YHN7UJM(IK<”);
aes.Mode = CipherMode.CBC; // 暗号利用モードはCBC
aes.Padding = PaddingMode.PKCS7; // パディングは PKCS#7
// 文字列をバイト型配列に変換
byte[] src = Encoding.Unicode.GetBytes(“ほげほげほげほげほげほげほげほげほげ”);
// 暗号化する
using (ICryptoTransform encrypt = aes.CreateEncryptor()){
byte[] dest = encrypt.TransformFinalBlock(src, 0, src.Length);
return Convert.ToBase64String(dest); // BASE64化
}

余談：Base64・Base62・Base58
暗号化した文字列は、ほとんどの場合バイナリデータになる。
URL 等のパラメータとして暗号データを渡す場合、BASE64 を使うと
「+」「/」「=」などの文字列ではまりがち。
例えば「/」はURLエンコードすると「%2F」だが、ブラウザ(ガラケー?)
によっては <a href=“foo?aaa%2F”> の % 自体を URLエンコードしてしま
い、%252F と送ってきたりする。また、「+」がスペースになったりする。
そういうときは、BASE62 や BASE58 を使うと余計なところでハマらない。
BASE64： 0-9、a-z、A-Z、+、/ の 64文字と、パディングの =
BASE62： 0-9、a-z、A-Z の 62文字
BASE58： BASE62 から、見た目が判別しづらい 0・O・I・l を除外したもの。
BASE58 は flicker やビットコインで使われている。

DES の終焉
DES は鍵長56bit。
ハードウェア・ネットワークの進化により、どんどん短い時間で解析可能になって
いる。
distributed.net という団体が、何度かクラックコンテストを開催しているが、
1999年時点で1日かからずに解読に成功している (ただし専用ハード+世界中のPC
を使って)。
DES Challenge I 96日で解読 (1997年)
DES Challenge II-1 41日で解読 (1998年)
DES Challenge II-2 56時間で解読 (1998年)
DES Challenge III 22時間15分で解読 (1999年)

鍵長って大事
DES と RC5 という共通鍵暗号アルゴリズムの解読時間を比較してみる。
DES 40bit：数秒～30秒で解読 (2001年 CRYPTO2000 ランプセッション)
DES 56bit：22時間15分で解読 (1999年)
RC5 56bit：250日で解読 (鍵空間の47%を解析したところで発見)
RC5 64bit：4年間で解読 (鍵空間の83%を解析したところで発見)
RC5 72bit：開始から11年経過したが、2014/2 時点で鍵空間の 3.1% しか解析で
きておらず、解読できていない
鍵長が増える → 鍵のパターン数が増える → 総当り攻撃で見つかりづらくなる、と
いうこと。
「128bit は 64bit の 2倍の鍵空間」ではない。
2の64乗=18446744073709551616 倍の鍵空間を持つ。

3DES
3DES：鍵長168bit/112bit/56bit、ブロック長64bit
DES3・TripleDES と書くこともある。
「DES単体だと鍵長が短くのなら、3回DESで暗号化すればいいんじゃな
い?」という投げやりな暗号方式。
3DES は、DESで暗号化・復号・暗号化とする (暗号化を3回ではない)。
「鍵長168bit/112bit/56bit」とはどういうことかというと…
1回目の鍵：X、2回目の鍵：X、3回目の鍵：X
→ DES と同じ (56bit の強度)
1回目の鍵：X、2回目の鍵：Y、3回目の鍵：X
→ 112bit の強度
1回目の鍵：X、2回目の鍵：Y、3回目の鍵：Z
→ 168bit の強度
1つの実装で 3DES にも DES にも対応できるようにしている。

公開鍵暗号方式とは
公開鍵暗号方式とは?
共通鍵暗号方式は「鍵がひとつ。暗号化・復号いずれも同じ鍵を使う」であっ
た。
「自分ひとりが使う」のであれば共通鍵暗号方式で問題ない
例：他人に見られたくないファイルを暗号化してデスクトップにおいておく、
など
しかし、他人とのやりとりを暗号化する場合、共通鍵暗号方式だと「どうやっ
て鍵を相手に受け渡すか」が問題になる。
ネットワークは盗聴されているかもしれないので、ネットワークごしに鍵を渡
すことはできない。
電話は盗聴されているかもしれない。手紙は開封されるかもしれない。
→ 安全に受け渡す方法がない！ (これを鍵配送問題といいます)

公開鍵暗号方式とは
そこで発明されたのが公開鍵暗号方式。
鍵が2つある。誰にでも公開してもよい公開鍵と、秘密にするべき秘密鍵。
公開鍵で暗号化し、秘密鍵で復号することができる。
AさんにBさんからメッセージを送りたい場合：
1. Aさんが公開鍵を世界中にばらまく
2. Aさんにメッセージを送りたいBさんは、Aさんの公開鍵で暗号化し、Aさん
に暗号文を送る。
3. AさんはBさんから暗号文を受信し、Aさんの秘密鍵で復号する。
ここで「Aさん＝Webサーバ」「Bさん＝ブラウザ」とすると、SSL/TLS とな
る。

RSA
そんな都合のよい鍵が世の中に存在するのか?
→ 素数を使った RSA という暗号化方式が 1977年に発見された。
素数の性質：
・大きな素数を生成(発見)するのは高速に行える。
・大きな素数をかけあわせた数を素因数分解するのはとても時間がかかる。
この「非対称性」を使うことで「暗号化は簡単だけど、復号は難しい」を実現している。
例えば、
p=654673753499 (素数)
q=242789071243 (素数)
のとき、n=p*q は 158947632579190931529257 となる。ここまではコンピュータ
なら簡単に行える。
しかし、n (158947632579190931529257) を因数分解して p と q を取り出すことは
難しい。
これを利用して、RSA においては「n を公開鍵」「p・q を秘密鍵」とすることで、公
開鍵暗号方式の特性を満たしている。

RSA
>「n を公開鍵」「p・q を秘密鍵」
上記はあくまでイメージであって、正確には下記。
そんなに難しくはないし、RSAのサンプルプログラムはたくさん見つかるので、ぐぐっ
てみてください。
--------
素数 p, q を用意する。
n = p * q とする
p-1 と q-1 の最小公倍数 L を求める。
e と (p-1)*(q-1) の最大公約数が 1 となるような e を求める。
→ e は 3 とか 65537 がよく使われる。
(e * d) % L = 1 となり、かつ 1<d<L を満たす d を求める。
公開鍵は e と n
秘密鍵は d と n
暗号化：暗号文 = (平文^e) % n
復号：平文 = (暗号文^d) % n
--------

余談：素因数分解と素数の生成
余談：
因数分解を行う場合、2で割れるか、3で割れるか、5で割れるか、7で割れるか
…と順番に試していくのが最も簡単な方法だが、これだと時間がかかりすぎる
(前ページの例だと n は 84bit なので、やろうと思えばできそうだが、実際に
使われている RSA においては 1024bit や 2048bit の値を相手にしないといけ
ない)。
数体ふるい法など、よりエレガントな方法はあるが、それでも時間がかかる。
一方、素数の生成 (発見) は、「ミラー-ラビン素数判定法」などの高速なアル
ゴリズムがある。ただし、あくまで「素数である可能性が極めて高い」という
判定しかできない。
(確定判定はできるが、時間がかかりすぎるので現実的ではない)

RSAビット数
RSAのビット数 (ここで言うビット数は、n (=p*q) のビット数のことです)
結論から言うと、2048ビットを使いましょう。
米NIST (国立標準技術研究所) が政府標準の暗号を決定する際、「RSA 1024ビットは安
全性が低いので使うな！でも2010年までは許す！」と宣言しました。これを受け、ベリ
サイン等の認証局も 2010～2012年あたりで RSA 1024ビットの受付を終了しています。
なお、RSAを発見したRさんとSさんとAさんが作ったRSAセキュリティ社では、RSA解
読のコンテストをやってます。現在 RSA 768bit まで解読されています。
チャレンジ名ビット数終了時期
RSA-129 428bit 1994年4月27日
RSA-140 466bit 1999年2月2日
RSA-155 512bit 1999年8月22日
RSA-160 (ここまで桁数) 530bit 2003年4月1日
RSA-576 (ここからビット数) 576bit 2003年12月3日
RSA-640 640bit 2005年11月2日
RSA-768 768bit 2009年12月(Opteron2.2GHz 600個×3年間に相当)
RSA-1024 1024bit 未解読
RSA-2048 2048bit 未解読

RSA 512bit の小ネタ
●RSA 512bit の小ネタ：
2012年に、Google採用チームからの「Googleで働きませんか?」というヘッド
ハンティングのメールを受信した数学者のザッカリー・ハリス氏。
このメールが本当に Google から届いたものか疑問に思った彼がメールをしら
べているうちに、DKIM (Domainkeys Identified Mail) を使った署名において
使用されている Google の公開鍵が RSA 512ビットであることとを発見。
Amazon EC2 にてインスタンスを数個立ち上げて解析プログラムを実行した結
果、72時間以内に鍵を発見し、Google創業者のサーゲイ・ブリン氏から
Google CEO であるラリー・ペイジ氏にあてたように見せかけたメールを送信
した。返信はなかったが、2日後にGoogleの鍵は2048ビットに変更されていた。
US-CERT がこの件を警告した結果、Google 以外にも、Microsoft・Y!・
Amazon・Apple・Twitter 等々で 1024bit 未満の不適切な鍵の使用が発覚。
→ 「RSAだから安全」ではない。適切な鍵長を使いましょう。

RSAのデータ長
RSA が扱えるデータ長：
RSA 1024bit のとき、扱えるデータは 1024bit あたりまで。
RSA 2048bit のとき、扱えるデータは 2048bit あたりまで。
(暗号化・復号においては n で割った余りが結果となるので、n を超えることは
ありえない)。
長いデータを扱えないので、DES などの共通鍵暗号方式と同様に、長すぎる場
合の分割方法やパディング等が規格としてまとめられている (RSA_PKCS#1
v1.5 や、RSA_OAEP 等)。よって、実利用する場合は特に考えなくてよい。

RSAの欠点
RSA の欠点：
遅い！
DES や AES 等の共通鍵暗号とくらべて 1000倍遅いと言われている。
よって、SSL/TLS においては、共通鍵暗号方式と組み合わせて使われている。

RSA以外の公開鍵暗号方式
●楕円曲線暗号 (ECC)
y2 = x3 + ax + b といった楕円曲線において、掛け算的なことは簡単にできるが、割
り算的なことは難しいという特性を用いたもの。サーバ・ブラウザ等の実装が進み、
2013年あたりから ECC な SSL 証明書が発行されている。
ウリとしては、ECC 256ビットで、RSA 3072
ビット相当の強度を持ち、RSA と比較して高速
であること。鍵送信時のデータ量削減と、
サーバ負荷軽減につながる。
ECCの欠点：
certicom 社の特許料が不透明な感じ(?)
MS の DRM では昔から使われている模様。
SSLにおけるRSA4096/2048/1024 それぞれ
の処理速度(X軸が新規SSLのセッション割合、
Y軸が処理速度。傾きが大きいのがRSA4096。
小さいのがRSA1024)

RSAと公開鍵暗号方式
RSAは、秘密鍵で暗号化して公開鍵で復号できるが、逆に公開鍵で暗号化して
秘密鍵で復号することもできる。
これは RSA がたまたまそういうつくりであるだけであり、公開鍵暗号方式全て
にあてはまるものではない。

ストリーム暗号
ストリーム暗号：共通鍵暗号の一種。
ブロック暗号のように 64bit や 128bit などのブロック単位でデータを暗号化するので
はなく、ビット単位またはバイト単位で暗号化できるもの。ブロック暗号より高速なの
がウリ。
ストリーム暗号の例：
・RC4
・SEAL
等々
ブロック暗号で代用できるため、最近はストリーム暗号はあまり流行らないのかもしれ
ない。

小ネタ： RC4 と ARC4
●小ネタ： RC4 と ARC4
RSA 社が 1987年に作ったストリーム暗号。仕組みは非公開であったが、あるメーリン
グリストに匿名でソースが投稿され、即ネットニュース等に転載され、世界中が知るこ
ととなった。このソースは ”Alleged RC4” (RC4 だと言われている物) と呼ばれるよう
になり、”ARC4” “ARCFOUR” とも書かれる。RSA社は認めてはいないが、セキュリティ
業界的には RC4 ＝ ARC4 ＝ ARCFOUR とみなされている。
無線LAN関係のWEP・WPA や、SSH・SSL/TLS 等で使われている。WEP において
RC4 の使い方の問題による脆弱性があり、なんとなくイメージが悪いような気がするが、
RC4 において致命的な問題があるわけではない。
ただ、致命的ではないが、そろそろまずいのではという話も出ており、RC4 が生成する
乱数に若干の偏りがある(2個目の数字がゼロになる確率が、他の数字より2倍程度高い)
ため、2^33～2^34 回程度観測を続けると HTTP cookie が盗聴できるレベルになると
のこと。
2013年になって、Microsoft が SSL/TLS で RC4 を無効化するようアドバイサリを出し
たり、日本政府推奨のリストから 128bit RC4 が外されたりしている。

ハッシュアルゴリズム
ハッシュアルゴリズム (ハッシュ関数) とは：
どんな長さのデータ、どんな内容のデータを与えても、決まった長さの
値を返すもの。
同じ値を与えれば、必ず毎回同じ結果になる。
復号できないので暗号化ではない。
鍵は存在しない。入力データのみで結果が決まる。
結果から、元の値を推測することはできない。
文字列ハッシュ値
aa d404401c8c6495b206fc35c95e55a6d5
bb bfcc9da4f2e1d313c63cd0a4ee7604e9
cc 870c06c00566c4fb1861bb10f34d1904

MD5
ハッシュアルゴリズムの実例： MD5 (Message Digest Algorithm 5)
128bit の出力をするハッシュ関数。
RSA の R さんが開発した。
例： Linux の md5sum コマンド
% md5sum file.txt
30ad0c5b76090a9011e83a2b4482148a
→ file.txt の内容を入力値とし、ハッシュ値を出力
(どんな長さのファイルを与えても、同じ長さになる)

SHA
ハッシュアルゴリズムの実例： SHA (Secure Hash Algorithm)
現時点ではSHA-2 がよいと思われる。
SHA名称出力長備考
SHA-0 160bit 使わないほうがよい
SHA-1 160bit 使わないほうがよい
SHA-2 (SHA-224) 224bit
SHA-3 (SHA3-224) 224bit
SHA-3 (SHA3-256) 256bit
SHA-3 (SHA3-384) 384bit
SHA-3 (SHA3-512) 512bit

強衝突耐性と弱衝突耐性
強衝突耐性：
同じハッシュ値をもつ２つのデータの作りにくさ。
弱衝突耐性：
あるハッシュ値を持つデータの作りにくさ。
例えばMD5 は、強衝突耐性は破られているが、弱衝突耐性は突破されていない。
強衝突耐性が破られているとは、同じハッシュ値が出力されるような2つのデータ
を簡単につくれるということ。ただ、現実的にはそれができたからといって大問題
になるわけではない。
弱衝突耐性が破られたら、それは元データを変更しつつもハッシュ値を変えない、
つまり改ざんが可能ということであり、全く使い物にならなくなる。

強衝突耐性と弱衝突耐性
MD5 の小ネタ：
オーストラリアにてオービスにてスピード違反として摘発されたドライバーが、写
真データのハッシュとしてMD5を使用しているが、MD5 は強衝突耐性が破られて
いるためその写真は信用できないと裁判に訴えた結果、勝訴となり、違反取り消し
となった。
つまり「MD5には脆弱性があり、写真のナンバープレート部分を修正した上で、元
のMD5と同じ結果が得られるのだから、写真が改ざんされていない証拠にはならな
い」と主張して、認められたということ。しかし改ざんを行いつつもハッシュ値を
変えない、とする場合は弱衝突耐性を突破する必要があるが、MD5 では弱衝突耐
性はまだ破られていないため、この主張はおかしい。
その後、警察(?)が「MD5 に加えて SHA-1 でもハッシュを取っているので
証拠として有効である」と声明を出したらしい。
その後どうなったのか不明。

ハッシュの使いどころ
・改ざんの検出
・チェックサム
・パスワード保存
パスワードを SHA-1 でハッシュ化した結果を DB に保存しておく。
次回ログイン時は、入力されたパスワードを SHA-1 でハッシュ化し、
DB の値と一致すればログインOKとする。
万が一 DB の内容が漏洩したとしても、ハッシュ化された値から
元の値を求めることは困難なので、第三者がログインすることはできない。

レインボーテーブル
パスワード保存はハッシュ化しておけば安心、というわけではない。
例えば、適当な文字列とそれをハッシュした値のテーブルをあらかじめ作っておき、
DBに保存されているハッシュ値と照合するという手法がある。
しかし、文字列を128bit、ハッシュを128bitとして、128bit分のすべてのハッシュ
値を計算しておくと、データ量が半端ない。
9600000000000000000000000ペタバイトくらい必要。
aa d404401c8c6495b206fc35c95e55a6d5
bb bfcc9da4f2e1d313c63cd0a4ee7604e9
cc 870c06c00566c4fb1861bb10f34d1904
・・・・・・・

レインボーテーブル
そこでレインボーテーブル。「ハッシュ→平文」を変換を行う「還元関数」を用い
る (このとき、英数字のみなどと文字種を絞り込む)。赤枠部分だけ保存しておけば
よい。
※上記画像は http://dev.classmethod.jp/security/rainbowtable/ より拝借。
http://md5decryption.com/ など、Web 上で解読可能なサービスもある。
レインボーテーブルは MD5に限らず、SHA-1・SHA-2 などにも適用可能。

salt (ソルト)
salt (ソルト) =「塩」。
暗号化またはハッシュ化する際に、適当なデータを先頭や末尾にくっつけること。
例えば abc という脆弱なパスワードを使うと、レインボーテーブルや総当り攻撃を
使って、ハッシュ値から元のパスワードが推測されやすい。
パスワード文字列ハッシュ値
abc 900150983cd24fb0d6963f7d28e17f72
3N$.<_Q2abc 184d37f55640c50bae687a76abe0abea
例えば salt を “3N$.<_Q2” とし、パスワードの先頭にくっつけてからハッシュ値
を計算する。$ や < などの記号まで含めたレインボーテーブルは現実的には構築困
難であるため、「パスワード自体の短さ」「文字種の少なさ」などの弱みを補うこ
とができる。

salt (ソルト)
○salt には何を選べばよいか?
・システム固有の文字列
例: NS37q2$+Z”x
・システム固有の文字列 + user_id などの数字
例: NS37q2$+Z”x1234567
・ランダム文字列
○saltはどこに保存すればよいか?
・システム固有の文字列の場合 → DB でも設定ファイルでも
・ランダム文字列の場合
→ ハッシュ化したパスワードの先頭とか、salt カラムを作ってそこに保存とか
※salt は秘匿する必要はない。

ストレッチング
ストレッチングとは
ハッシュ化する際に、SHA-2 などのハッシュ関数を1回だけ使うのではなく、
1000回とか1万回とか繰り返すこと。
総当り攻撃やレインボーテーブルとの照合する際に、ハッシュ関数を1万回まわす
必要が出てくるので、攻撃が難しくなる (時間がかかる)。
一方、パスワード設定やログイン時にハッシュ関数を1万回まわしたとしても、
1秒程度で処理が完了するため、サイト運営側としては「ログイン時に少し時間が
かかる」程度の影響しかない。

SSL/TLS
SSL/TLS (画像は http://www.twsvc.com/about_ssl より拝借)

SSL/TLS
サーバ証明書の例 (シマンテックのサイトより)
https なサイトにアクセス
すると、自動的にサーバに
ある証明書を取得する。
これが公開鍵。
公開鍵で暗号化すると、
サーバ側にしかない秘密鍵
でしか復号できない。

SSL/TLS
SSL/TLS における共通鍵
共通鍵暗号方式はRC4
128bit。

SSL/TLS
SSL/TLS における署名とは：
あるデータのハッシュ値を求め、
公開鍵暗号方式の公開鍵・秘密鍵のペアのうち、秘密鍵で暗号化したもの。
公開鍵で復号することで、「秘密鍵を持っている人が署名した」ということを
検証できる。
サーバ証明書の検証：
「サーバから送られてきたサーバ証明書が正しいのか?」「第三者に通信が改ざん
されているのではないか?」「別のサーバに転送されているのではないか?」
という疑問を解決するためには・・・
サーバ証明書に含まれている署名を、ブラウザにあらかじめインストールされてい
る「ルート証明書」で検証する。この検証が成功したら、ベリサイン等の認証局で
発行したものである、との確信が得られる。

暗号技術まとめ
共通鍵暗号方式
ブロック暗号: AES・DES・3DES 等
ストリーム暗号： RC4・SEAL
公開鍵暗号方式
RSA
ECC
ElGamal 等
ハッシュアルゴリズム
MD4
MD5
SHA-1
SHA-2
署名
RSA
DSA (ElGamal署名を改良したもの)
プロトコル
SSL/TLS
SSH

おしまい

人生を豊かにするための暗号技術の話 - ネクストスケープ 2014/04/24 パワーランチ資料

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (14)

Featured

Featured (20)

人生を豊かにするための暗号技術の話 - ネクストスケープ 2014/04/24 パワーランチ資料