「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- 暗号の基礎については、コチラ
- .NETのアルゴリズムは、コチラ
を参照。
ハッシュ化 †
ハッシュ化とは、「ハッシュ関数」を用いて指定のメッセージの「ハッシュ値」を求める行為である。
ハッシュ値 †
「メッセージ ダイジェスト」、あるいは単に「ダイジェスト」と呼ぶことがある。
認証アルゴリズムの「ダイジェスト認証」や、「チャレンジ＆レスポンス認証」で使用されている。
目的によってはハッシュ値のことを「フィンガープリント」、「チェックサム」とも呼ぶ。
ココでは、正確には「暗号学的」ハッシュ関数について。
など、様々に利用されている。
- また、通常のハッシュ関数としても利用でき、
- ハッシュテーブル（テーブルのキー）
- ダイジェスト、フィンガープリント（認証）
- データ、ファイルの一意識別、重複検出
- チェックサム（データの誤りを検出）
などの用途にも利用されている 。
- 既成の「ハッシュ関数」を使用した場合、
以下が満たされているものとして利用できる。
- 衝突発見困難性
ハッシュ値を変えずに元のメッセージを改ざんすることが事実上不可能であること。
- 第二原像計算困難性
同じハッシュ値を持つ2つの元のメッセージを求めること（すりかえ）が事実上不可能であること。
- 不可逆性 / 一方向性（原像計算困難性）
ハッシュ値から元のメッセージを得ることが事実上不可能であること。
- 以下の順序で難しい。
- 不可逆性 / 一方向性（原像計算困難性）
- 第二原像計算困難性
- 衝突発見困難性
安全性 †
キーなし方式・あり方式 †
「暗号学的ハッシュ関数」には、
- ハッシュ計算用のキーを取れないもの（キーなし方式）と、
- キーを取れるもの（キーあり方式）が存在する。
「暗号学的ハッシュ関数」自体は不可逆であるものの、
「キーなし方式」の場合、辞書攻撃 により、容易にメッセージが割れる可能性がある。
このため、辞書攻撃を防ぐ場合、「キーあり方式」を採用する。
衝突耐性 †
「暗号学的ハッシュ関数」を使用する際は、
最新の「ハッシュの衝突耐性」の情報を入手する事が推奨される。
これは、例えば、2010/5現在、MD5、SHA-0、SHA-1について
「強衝突耐性」が突破される脆弱性が発見されているためである。
ただし、「強衝突耐性」が突破されても、直ちに、これらの「暗号学的ハッシュ関数」を用いている
暗号化通信が盗聴・改ざんされたり、電子署名の有効性が無くなったりすると言うわけではない。
これは、将来的な「弱衝突耐性」の突破を示唆し、「弱衝突耐性」が突破された場合は、
暗号化通信や電子署名の無改ざん性を証明できなくなる。
キーなし方式 †
キーあり方式 †
暗号化 †
暗号化の方式には、大きく分けて、
- 秘密鍵・暗号化
暗号化と復号が同じ処理であるところから、「対称アルゴリズム」とも呼ばれる。
- 公開鍵・暗号化
暗号化と復号が違う処理であるところから、「非対称アルゴリズム」とも呼ばれる。
の２つの方式がある。
以下の表に「秘密鍵・暗号化」と、「公開鍵・暗号化」との比較を示す。
なお、両者のメリット・デメリットを考慮し、両者を組み合わせたハイブリッドの方式もある。
これについては、「ハイブリッド・暗号化方式」の項にて説明する。
- ※1 : 「秘密鍵・暗号化」は、暗号化と復号化に使用する鍵が、
同一の秘密鍵であることから、「共通鍵・暗号化方式」とも呼ばれる。
- ※2 : 「秘密鍵・暗号化」の鍵はパスワードのようなもので、
基本的に相手毎に、この秘密鍵（パスワード）を変えることが望ましい。
従って、相手が増えるほど管理する秘密鍵が増える。
ただし、自分のために暗号化し、自分だけが復号化する場合は、秘密鍵は１つでも良い。
- ※3 : アルゴリズムが非対称であると、数学的に難しい処理が多く、高速での処理が難しくなるため。
秘密鍵・暗号化 †
概要 †
- 「秘密鍵・暗号化」は、
- 秘密鍵を使用して暗号化・復号化を行う。
- 秘密鍵として、任意のキー（パスワード）を使用できる。
- この方式は、
秘密鍵の受け渡しと、管理が困難となるため、
不特定多数のユーザとネットワーク越しの
情報受け渡しを行うC/Sシステムには使用されない。
アルゴリズム †
鍵の数 †
- 具体的には、ｎ人で、（ｎ（ｎ－１））÷２個の鍵が必要になる
公開鍵・暗号化 †
概要 †
- この方式は、
公開鍵で暗号化したものは、秘密鍵でしか復号できないと言う性質を利用して、
不特定多数のユーザとネットワーク越しの情報受け渡しを行うC/Sシステムに使用される。
処理シーケンス †
- 処理シーケンスは次のようになる。
- 送信側は、「受信側の公開鍵」を取得する。
- 送信側は、平文を「受信側の公開鍵」で暗号化する。
- 上記、暗号化された平文を送付する。
- 受信側は、平文を、「受信側の秘密鍵」で復号化する。
アルゴリズム †
鍵の数 †
- 公開鍵の場合は、各人が秘密鍵・公開鍵のペアを持てばイイ
- 具体的には、ｎ人で、２ｎ個の鍵が必要になる。
.NETにて提供されるRSACryptoServiceProvider?を使用した場合、
- 同じ公開鍵を使用しても暗号化情報は可変になるが、
同じ秘密鍵で復号化が可能であるので、リプレイ攻撃の対象になる。
- このため、公開鍵・秘密鍵のキー・ペアを可変にするか、
チャレンジを加えるなどの実装を追加する必要がある。
なお、リプレイ攻撃とは、ユーザがログインするときにネットワークを流れる電文を盗聴し、
これを自分の送信する電文として利用することでシステムへ不正にログインしようとする行為を指す。
ハイブリッド・暗号化（キー交換） †
秘密鍵・暗号化、公開鍵・暗号化の両者のメリットとデメリットを考慮し、
組み合わせた「ハイブリッド・暗号化方式」もある。
一般的には、アリスとボブ - Wikipediaで知られている。
処理シーケンス †
- 処理シーケンスは次のようになる。
- 送信側は、「受信側の公開鍵」を取得する。
- 送信側は、「送信側の秘密（共通）鍵」を、「受信側の公開鍵」で暗号化する。
- 上記、暗号化された「送信側の秘密（共通）鍵」を送付する。
- 受信側は、「送信側の秘密（共通）鍵」を、「受信側の秘密鍵」で復号化する。
- 送信側は、平文を「送信側の秘密（共通）鍵」で暗号化する。
- 上記、暗号化された平文を送付する。
- 受信側は、平文を、「送信側の秘密（共通）鍵」で復号化する。
- 「公開鍵・暗号化」で「送信側の秘密（共通）鍵」を共有し、
平文自体は速度の速い「秘密鍵・暗号化」で暗号化・復号化するため、
「安全性」を落とさずに、処理速度を稼ぐことができる。
- また、「送信側の秘密（共通）鍵」（セッション鍵）をセッション毎に変更すれば、
万一共通鍵での暗号部分が解読されても短い時間しかクラッキングできなくなる。
- なお、SSL暗号化なども、この「ハイブリッド・暗号化方式」を採用している。
PFS（Perfect Forward Security） †
- 暗号文とその暗号文を複合するための秘密鍵が両方漏洩しても、
暗号文を複合できない、というカギ交換に関する概念
- PFSを実現可能にするためのアルゴリズム
- DHE：ディフィー・ヘルマン鍵共有
- ECDHE：楕円曲線ディフィー・ヘルマン鍵共有
- SSL/TLSでは、証明書と組み合わせた以下の何れかの方式を使う。
- DHE-RSA
DHEとRSA証明書の組み合わせ
- DHE-DSA
DHEとDSA証明書の組み合わせ
- ECDHE-RSA
ECDHEとRSA証明書の組み合わせ
- ECDHE-ECDSA
ECDHEと楕円曲線DSA証明書の組み合わせ
- 公開鍵は
- 何かしらの証明を付けた静的なものであっても、
- 一時的なもの（ephemeral、この場合特にDHE、ECDHEと略記される）
であってもかまわない。
アルゴリズム †
デジタル署名 †
概要 †
「デジタル署名」は、元となるメッセージのハッシュを秘密鍵で暗号化したものである。
送信元が、この「デジタル署名」を、元となるメッセージと同梱して送付することにより、
送信先は、元となるメッセージの正当性を（＝ 改ざんされていない事を）検証できる。
処理シーケンス †
- 処理シーケンスは次のようになる。
- 送信側は、「メッセージ」から「メッセージのハッシュ」を求め、
これを「送信側の秘密鍵」で暗号化することで、「デジタル署名」を生成する。
- 送信側は、「メッセージ」、「デジタル署名」を送付する。
- 受信側は、「デジタル署名」を、「送信側の公開鍵」を使用して、
復号化することで、「メッセージのハッシュ」を求め、メッセージを検証する。
- 以下の図に「デジタル署名」の処理方式の概要図を示す。
- このことから、「デジタル署名」は、
「公開鍵・暗号化」とは逆に「非対称アルゴリズム」を
使用していることが分かる（秘密鍵で暗号化し、公開鍵で復号化）。
アルゴリズム †
「デジタル署名」では、秘密鍵・公開鍵のキー・ペアを、プロバイダを使用して生成する必要がある。
認証 †
メッセージ認証符号（MAC） †
概要 †
- 暗号学的ハッシュ関数との違い
MAC関数は選択平文攻撃における存在的偽造に対して耐性がなければならない。
つまり、共通鍵を持ちMAC関数を計算できる"復号オラクル"にアクセスできる
攻撃者が、任意に選んだメッセージに対応するMACを取得できたとしても、
他の（"復号オラクル"に問い合わせていない）メッセージに対するMACを
"復号オラクル"に対して問い合わせずに計算で求めることが計算量的に困難でなければならない。
- デジタル署名との違い
- MAC値の生成と検証には同じ鍵（共通鍵暗号）が使われるので、
送信者と受信者は通信を行う前に鍵を共有しておく必要がある。
- また、共通鍵暗号であるために、MACによって認証されるメッセージは、
偽造ではなく送信者が作成し送信したという確証、つまり否認不可性をもたない。
なぜなら、MAC値を検証する利用者（メッセージの受信側）は、
通信の相手から受け取ったメッセージではなく、受信側で捏造したメッセージ
についても共通鍵を使ってMAC値を生成することができるからである。
処理シーケンス †
https://ja.wikipedia.org/wiki/%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8%E8%AA%8D%E8%A8%BC%E7%AC%A6%E5%8F%B7#/media/File:MAC.svg
例：SSH2のトランスポート層のデータ一貫性を確保するためのMAC用の共通鍵を、
ハイブリッド・暗号化のECDHで生成された共通鍵からハッシュ関数によって生成される。
アルゴリズム †
- 概要
MACアルゴリズムは他の暗号プリミティブから構築できる。
- ハッシュ関数（キーあり方式）を使う方式（HMAC、3DES）
- ブロック暗号アルゴリズムを使う方式（OMAC/CMAC、CBC-MAC、PMAC）
- HMAC (Hash-based Message Authentication Code) とは、
- 種類
- HMAC-MD5
- HMAC-Ripemd-160
- HMAC-SHA1
- HMAC-SHA256
- HMAC-SHA384
- HMAC-SHA512
- CMAC (Cipher-based Message Authentication Code) とは、
- 種類
- CBC-MAC
- CFB, OFB-MAC等は無い。
APIインターフェイス †
- 入力として共通鍵と認証すべき任意長のメッセージを受け取る。
- MAC（「タグ」とも呼ばれる）を出力する。
MAC値は（、共通鍵をもつ）、検証者がメッセージの内容の変化を
検出できるようにして、メッセージの完全性を保護し、認証する。
認証付き暗号（AEAD） †
概要 †
- 説明
- Authenticated Encryption with Associated Dataを略してAEADとも呼ばれる。
- MACと対称暗号を組み合わせて、機密性(暗号)、認証・正真性(MAC)を満たす仕組み。
- AEAD(認証付き暗号)では不適切に細工された暗号文を識別(MACの認証と正真性)して
復号を拒否することができるため、選択暗号文攻撃に対して安全になる。
- データの秘匿性、完全性、および認証性を同時に提供する暗号化モードで、復号すると同時に完全性も検証される。
＝秘匿性と完全性の保護に加えて、認証付き暗号は平文既知性 (PA: plaintext awareness) を備えており、選択暗号文攻撃に対して安全である。
- この種の攻撃で敵は、よく考えられた暗号文を "復号オラクル" に渡して復号結果を分析することで、暗号システムの攻略ヒントを得ようとする。
- 認証付き暗号システムは不適切に細工された暗号文を識別して復号を拒否することができる。
- 適切に暗号化アルゴリズムを使って生成（≒平文を既に知っている）しない限り暗号文の復号要求を防ぐということである。
- 適切に実装されていれば、これにより攻撃者が既に知っている以上の有用な情報を復号オラクルで取り出せないようになる。
- 認証付き暗号対応のクラスライブラリを使用すれば、こうした特性がまとめて提供される。
- 秘匿用モードと認証用モードを安全に合成するのが困難であろうとの報告により、AE の必要性が明らかになった。
処理シーケンス †
- 共通鍵ブロック暗号で使うための認証付き暗号専用のモードも数多く開発されているが、
一般的に認証付き暗号は、以下要件を満たす暗号システムとメッセージ認証符号（MAC）を組み合わせて構成する。
- 暗号システム：選択平文攻撃のもとで強秘匿性を有する必要がある。
- MAC関数：選択メッセージ攻撃のもとで偽造不可でなければならない。
- 認証付き暗号の手法
Bellare and Namprempre (2000) はこうしたプリミティブの組み合わせを三通り考察し、
暗号と MAC 双方の関数が必要な性質を満たす場合は、メッセージを暗号化してから
暗号文に MAC を計算することで適応的選択暗号文攻撃に対し安全であることを実証した。
- Encrypt-then-MAC (EtM)
- Encrypt-and-MAC (E&M)
- MAC-then-Encrypt (MtE)
アルゴリズム †
6種類の異なるモードが、
ISO/IEC 19772:2009 によって標準化され、
さらにNISTによって開発がすすめられた。
- OCB 2.0
- Key Wrap
- EAX
- Encrypt-then-MAC (EtM)
APIインターフェイス †
AEADの典型的な APIインターフェイス は次のような関数を提供する:
- 暗号化
- 入力
- 鍵
- 平文
- 追加認証データ（AAD）
アルゴリズムによっては必要になる。
認証や完全性保護のためにあり、
暗号化はされないが認証保護の対象。
- 復号化
- 入力
- 鍵
- 暗号文
- 認証タグ（MAC）
- 追加認証データ（AAD）
- 出力
- 平文
- 平文が、認証タグ（MAC）、追加認証データ（AAD）に合致しない場合はエラー
.NETの認証付き暗号のプロバイダ †
- Security.Cryptography.AuthenticatedAes?
- 昔、codeplexで提供されていたSecurity.Cryptography.AuthenticatedAes?辺りを使用可能。
- ただし、現在は、GitHubに移動されているが、メンテナンスされておらず、.NET Core対応がされていない。
その他 †
パスワードを格納する方式 †
WebサイトのForms認証などを実装する場合、ハッシュのみ保管が一般的。
ハッシュのみ保管 †
パスワードのハッシュ値のみ保存する方式。
- メリット
- 暗号学的ハッシュ関数の「不可逆性」「衝突困難性」を利用する。
- パスワードの代わりハッシュ値のみを保存すると鍵管理の煩わしさがない。
- パスワード・リマインダを実装できない
（昨今、パスワード・リセットが一般的で、実装不要）。
- パスワードの保存方法の変更が難しくなる。
（次回認証時のパスワード入力を待って変更することは可能）
※ ベスト・プラクティス
暗号化して保管 †
昨今、あまり選択されない方式。
パスワードを暗号化して保存する方式としては、「秘密鍵・暗号化」と「公開鍵・暗号化」があるが、
ユーザは不特定多数でなく、サーバ機能上で暗号化・復号化を行うだけであるため、「公開鍵・暗号化」を使用する。
ベスト・プラクティス †
ベストプラクティスは、後者。
- ソルトの意味
同じパスワードでも、ユーザーごとに異なるソルトを使い異なるハッシュ値にできる。
- ストレッチングの意味
- 高速なハッシュを繰り返し用いることで速度を遅くする。
- これにより、オフライン総当たり攻撃を妨害する。
ネットワークへパスワードを流す方式 †
- セキュアな認証基盤では、ネットワーク上に流すパスワードは、平文以外で流す必要がある。
- パスワードを平文以外でネットワーク上に流す方式として以下の方式が考えられる。以下、それぞれの方式の詳細について説明する。
HTTPS †
一般的にはコレ。
- 平文で送信される基本認証、Forms認証のユーザアカウントの暗号化
- HTTPSは、共通鍵が通信セッション 毎に可変となるため、リプレイ攻撃 に対しても対処できる。
チャレンジ＆レスポンス †
NTLMやCHAPなどで採用されている方式。
- 「暗号学的ハッシュ関数」（キーなし方式）では、リプレイ攻撃の対象となり得るため、
- チャレンジ（認証する側が認証される側に送信する乱数とID）と、
- 「暗号学的ハッシュ関数」（キーあり方式）
を使用してパスワードをハッシュ化してネットワーク上に流す。
- 可変のハッシュ（レスポンス）を元に認証処理を遂行するため、
認証基盤側は、ユーザ アカウント（パスワード）を平文で保持している必要がある。
公開鍵・暗号化 †
- 「公開鍵・暗号化」では、同じ公開鍵を使用しても暗号化情報は可変になるが、
同じ秘密鍵で復号化可能であることが確認でき、結局、リプレイ攻撃の対象となり得る。
- このため、「公開鍵・暗号化」を使用してパスワードを暗号化してネットワーク上に流す場合、
元となるメッセージにチャレンジを加え暗号化するなどの実装を追加する必要がある（ハイブリッド・暗号化 ）。
ネットワークへ認証チケットを流す方式 †
OpenID ConnectにおけるJWTの用例などが参考になる。
暗号化の詳細 †
初期化ベクトル †
初期化ベクトル（IV: Initialization Vector）
- ストリーム暗号
（IVを、）鍵ストリーム（擬似乱数列）の生成に利用する。
- ブロック暗号
（IVを、）
- 最初のブロックに使用されるベクトル値とする（＝共通鍵）。
- 暗号化モードで前の平文ブロックの結果を次の平文に使用する。
ストリーム暗号 †
概要 †
- ビット、バイト、文字毎に処理
- ブロック暗号より仕組みが単純で高速
- 暗号化してもデータサイズが変化しない（通信処理に適する）。
詳細 †
鍵ストリーム（擬似乱数列）
- を、共通鍵や初期化ベクトルをシード（初期値）として生成。
- と、平文 / 暗号文との排他的論理和で暗号化 / 復号化する。
アルゴリズム †
- KCipher-2
九州大学とKDDI研究所により共同開発
- Salsa20
ダニエル・バーンスタインによって開発（パブリック・ドメイン）
- RC4
SSLやWEPなどで広く使われているが、危殆化が進んでいる。
- MUGI
日立製、推奨暗号リスト → 推奨候補暗号リスト
- A5/1
GSM携帯電話規格で利用されていたが、
リエンジで脆弱性が見つかっている。
ブロック暗号 †
概要 †
- ブロック毎に処理
- ストリーム暗号より仕組みが複雑で低速
- 空きはパディングするのでデータサイズが増加する。
- そのままでは、暗号強度が弱いので、鍵ストリーム（擬似乱数列）代替として、
前ブロック値を平文 / 暗号文との排他的論理和に使用する暗号化モードがある。
詳細 †
- 通常、暗号化は鍵のサイズと同じバイト長を１ブロックとして暗号化する。
1024ビットの鍵ならば = 1024 / 8 = 128バイトを１ブロックとして暗号化する。
- アルゴリズムによって、以下が、決まっていることがある。
アルゴリズム †
- DES, DES-X, 3DES
- DES : 1977以降の米国政府の標準
- DES-X : 鍵長のみを長くした。
- 3DES : DESを3重に適用した。
- RC2, RC5, RC6
ロナルド・リベストが設計
- IDEA
スイス工科大学のXuejia Laiにより開発。
- CAST-128, CAST-256
設計者の頭文字を取ってCAST、数字は鍵長（最大値）
処理シーケンス †
- 暗号化
- アルゴリズムに対応したブロック長に分割する。
- ブロック長に満たない部分をパディング方式で補完する。
- 暗号鍵を用いてアルゴリズムで暗号化する。
- 分割されたデータを結合する。
- 復号化
- アルゴリズムに対応したブロック長に分割する。
- 暗号鍵を用いてアルゴリズムで復号化する。
- 補完された部分をパディング方式で除去する。
- 分割されたデータを結合する。
暗号化モード（暗号利用モード） †
- ブロック分割のメカニズム
- 分割モードによっては初期化ベクトルが必要になる。
- 認証用の利用モード、秘匿用の利用モードとがある。
- 認証用の利用モード
| # | | |
| 1 | CCM | Counter with CBC-MAC |
| 2 | OCB | Offset CodeBook? |
| 3 | XCBC | eXtended Ciphertext Block Chaining |
| 4 | XCBC-MAC | |
- 秘匿用の利用モード
| # | 暗号化モード（暗号利用モード） | 特徴 |
| 1 | ECB: Electronic CodeBook?
暗号ブックモード | ・単純にブロックに分割しそのまま暗号化するため、初期化ベクトルを必要としない。
・鍵と暗号対象データが同じであれば、同じ暗号データになるため、暗号文一致攻撃、暗号文改ざん攻撃に弱いという問題がある。 |
| 2 | CBC: Cipher Block Chaining
暗号文ブロック連鎖モード | ・最初のブロックについては最後のブロック or 初期化ベクトルと暗号対象データをXOR計算した結果を暗号化する。
・次のブロックについては、前の暗号化ブロックとそのブロックをXOR計算した結果を暗号化する。
・ブロック暗号をストリーム暗号のように利用するため、元のデータが部分的に同じで、鍵が同一でも一意の暗号データになり難い。 |
| 3 | CFB: Cipher-FeedBack?
暗号フィードバックモード | CBCと比較すると、初回のXORには暗号化したVIを使用する。
初回のブロックは、VIとのXOR処理のみの未暗号化ブロックで、
以降のブロックは、前のブロックを暗号化したブロックとそのブロックをXOR計算する。 |
| 4 | OFB: Output FeedBack?
出力フィードバックモード | ・初期化ベクトルを暗号化し、それをまた暗号化し、次々と乱数を生成する。
・その乱数列を XOR 演算によって平文に重ね合わせ暗号化処理を行う。
・ブロック暗号をストリーム暗号のように利用するため、元のデータが部分的に同じで、鍵が同一でも一意の暗号データになり難い。 |
| 5 | などなど他にも沢山ある | ・・・ |
パディングモード（パディング方式） †
- ブロック分割する時に
割り切れない場合は、パディングで穴埋めする。
- ZeroBytePadding?
- NULLバイト(0x00)でパディング
- 元データにNULLバイトが含まれていない場合でないと使えない
- PKCS#5 Padding (RFC1423)
- ブロック長に満たないサイズの値を表すバイト値で足りない分を埋める
- ブロック長ぴったりな場合は1ブロック分丸ごとパディングされる
- Optimal Asymmetric Encryption Padding（OAEP）
- 日本語で、最適非対称暗号化パディング
- PKCS#1 に定義されているOAEPWith<digest>And<mgf>Padding
- OAEPはRSAと組み合わせることが多く、その場合はRSA-OAEPと呼ばれる。
- その他
- SSL3Padding
- ISO10126Padding
- ISO10126d2Padding
- ISO7816d4Padding
- TBCPadding
- X9.23Padding
公開鍵・暗号化の詳細 †
計算の困難性を安全性の根拠とする暗号。
アルゴリズム †
RSA †
- RSA : Rivest-Shamir-Adleman cryptosystem
- 素因数分解問題（RSA暗号、Rabin暗号）を利用
巨大な素数同士をかけ合わせた整数の素因数分解の困難性。
DSA †
- DSA : Digital Signature Algorithm
- デジタル署名に利用でき、
暗号化には利用できない。
ECC（ECDSA, ECDH） †
- ECC : Elliptic Curve Cryptography
- 楕円曲線暗号
- 楕円曲線を利用した暗号方式の総称
- 楕円曲線上の離散対数問題の困難性に依る。
- ECDSA : Elliptic Curve DSA
- デジタル署名に利用でき、
暗号化には利用できない。
- ECDH : Elliptic curve Diffie–Hellman key exchange
- DH判定問題（Cramer-Shoup暗号）
(ga,gb)が与えられて、gabを求める問題の困難性に依る。
- 暗号化には利用できる（共通鍵の共有のための暗号化）。
- 以下の二種類のECDHがある。
・ephemeral-ephemeral : ECDHE
・ephemeral-static : ECDH-ES
離散対数問題 †
概要 †
- ２つのノードは素数 p と定数 g (p より小さい)を共有する。
- ある整数 x に対して g の x 乗を p で割った余りを y とする。
求める困難性に依る（素数 pが大きい値になればなるほど困難になる）。
詳細 †
- ２つのノードA（アリス）、ノードB（ボブ）は
素数 p と定数 g (p より小さい)を共有する。
- ノードA（アリス）は、
- 秘密鍵 x を生成し、(g^x) / p ... y を計算する。
- 公開鍵 y をノードBに送信する
- ノードB（ボブ）は、
- 秘密鍵 x' を生成し、(g^x') / p ... y' を計算する。
- 公開鍵 y' をノードAに送信する
- これにより、公開鍵の共有ができたので、
コレを使用して以下の共通鍵 a の共有を行う。
a = y'^x mod p = y^x' mod p
- ノードA
- x = 15
- y = (g^x) / p = 3,2768 / 41 = 798...9
- ノードB
- x' = 22
- y' = (g^x') / p = 4,194,304 / 41 = 102...4
- 共通鍵 a
- ノードA
a = y'^x mod p = 4^15 mod 41 = 40
- ノードB
a = y^x' mod p = 9^22 mod 41 = 40
DH鍵共有（交換） †
- ディフィー・ヘルマン鍵共有
- Diffie–Hellman key exchange
- 事前の秘密の共有無しに、
盗聴の可能性のある通信路を使って、
暗号鍵の共有を可能にする暗号プロトコル
と言う。
参考 †
暗号についての概要や体系や、各種の「暗号化アルゴリズム」の詳細については、
説明しないので、これについては、下記サイトや、他の情報源を参照のこと。
RFC †
Wikipedia †
ハッシュ関数 †
共通鍵暗号 †
公開鍵暗号 †
その他 †
Qiita †
「デジタル証明書」の検証は、「送信側の公開鍵」を拠り所にしていると言えるが、提供される「送信側の公開鍵」の出所が、正規の出所か、検証できない（場合がある）という問題がある。
このため、この問題を解決するための、「認証局」と呼ばれる、信頼のおける第三者が発行した「デジタル証明書」を使用して「送信側の公開鍵」が信頼できるものであるかを検証する機構がある。
パスワードの保存 †
ソルト、ストレッチング †
ハッシュとソルト、ストレッチングを正しく理解する：本当は怖いパスワードの話 - ＠IT
http://www.atmarkit.co.jp/ait/articles/1110/06/news154.html
暗号の年問題 †
なお、各種の「暗号化アルゴリズム」の「安全性」の問題については、
日々、調査・研究が進められていため、NIST やCRYPTREC などから
公にアナウンスされる情報源を確認のこと。
.NET Framework、.NET Coreのライブラリで提供される署名・暗号化アルゴリズム
Tags: :IT国際標準, :セキュリティ, :暗号化
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
DigitalSignature.png 1173件
[詳細]
HybridEncryptionScheme.png 1333件
[詳細]
PublicKeyEncryptionSchemes.png 1123件
[詳細]
ComparisonOfEncryptionScheme.png 1327件
[詳細]
CryptographicHashFunction.png 1101件
[詳細]
