![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
を参照。
ハッシュ化とは、「ハッシュ関数」を用いて指定のメッセージの「ハッシュ値」を求める行為である。
「メッセージ ダイジェスト」、あるいは単に「ダイジェスト」と呼ぶことがある。
認証アルゴリズムの「ダイジェスト認証」や、「チャレンジ＆レスポンス認証」で使用されている。
目的によってはハッシュ値のことを「フィンガープリント」、「チェックサム」とも呼ぶ。
ココでは、正確には「暗号学的」ハッシュ関数について。
など、様々に利用されている。
などの用途にも利用されている 。
「暗号学的ハッシュ関数」には、
「暗号学的ハッシュ関数」自体は不可逆であるものの、
「キーなし方式」の場合、辞書攻撃 により、容易にメッセージが割れる可能性がある。
このため、辞書攻撃を防ぐ場合、「キーあり方式」を採用する。
「暗号学的ハッシュ関数」を使用する際は、
最新の「ハッシュの衝突耐性」の情報を入手する事が推奨される。
これは、例えば、2010/5現在、MD5、SHA-0、SHA-1について
「強衝突耐性」が突破される脆弱性が発見されているためである。
ただし、「強衝突耐性」が突破されても、直ちに、これらの「暗号学的ハッシュ関数」を用いている
暗号化通信が盗聴・改竄されたり、電子署名の有効性が無くなったりすると言うわけではない。
これは、将来的な「弱衝突耐性」の突破を示唆し、「弱衝突耐性」が突破された場合は、
暗号化通信や電子署名の無改竄性を証明できなくなる。
暗号化の方式には、大きく分けて、
の２つの方式がある。
以下の表に「秘密鍵・暗号化」と、「公開鍵・暗号化」との比較を示す。
なお、両者のメリット・デメリットを考慮し、両者を組み合わせたハイブリッドの方式もある。
これについては、「ハイブリッド・暗号化方式」の項にて説明する。
- 送信側は、「受信側の公開鍵」を取得する。
- 送信側は、平文を「受信側の公開鍵」で暗号化する。
- 上記、暗号化された平文を送付する。
- 受信側は、平文を、「受信側の秘密鍵」で復号化する。
.NETにて提供されるRSACryptoServiceProvider?を使用した場合、
なお、リプレイ攻撃とは、ユーザがログインするときにネットワークを流れる電文を盗聴し、
これを自分の送信する電文として利用することでシステムへ不正にログインしようとする行為を指す。
秘密鍵・暗号化、公開鍵・暗号化の両者のメリットとデメリットを考慮し、
組み合わせた「ハイブリッド・暗号化方式」もある。
一般的には、アリスとボブ - Wikipediaで知られている。
- 送信側は、「受信側の公開鍵」を取得する。
- 送信側は、「送信側の秘密（共通）鍵」を、「受信側の公開鍵」で暗号化する。
- 上記、暗号化された「送信側の秘密（共通）鍵」を送付する。
- 受信側は、「送信側の秘密（共通）鍵」を、「受信側の秘密鍵」で復号化する。
- 送信側は、平文を「送信側の秘密（共通）鍵」で暗号化する。
- 上記、暗号化された平文を送付する。
- 受信側は、平文を、「送信側の秘密（共通）鍵」で復号化する。
「デジタル署名」は、元となるメッセージのハッシュを秘密鍵で暗号化したものである。
送信元が、この「デジタル署名」を、元となるメッセージと同梱して送付することにより、
送信先は、元となるメッセージの正当性を（＝ 改ざんされていない事を）検証できる。
- 送信側は、「メッセージ」から「メッセージのハッシュ」を求め、
これを「送信側の秘密鍵」で暗号化することで、「デジタル署名」を生成する。- 送信側は、「メッセージ」、「デジタル署名」を送付する。
- 受信側は、「デジタル署名」を、「送信側の公開鍵」を使用して、
復号化することで、「メッセージのハッシュ」を求め、メッセージを検証する。
「デジタル署名」では、秘密鍵・公開鍵のキー・ペアを、プロバイダを使用して生成する必要がある。
例：SSH2のトランスポート層のデータ一貫性を確保するためのMAC用の共通鍵を、
ハイブリッド・暗号化のECDHで生成された共通鍵からハッシュ関数によって生成される。
認証付き暗号(Authenticated Encryption with Associated Data)
6種類の異なるモードが、
ISO/IEC 19772:2009 によって標準化され、
さらにNISTによって開発がすすめられた。
AEADの典型的な APIインターフェイス は次のような関数を提供する:
WebサイトのForms認証などを実装する場合、ハッシュのみ保管が一般的。
パスワードのハッシュ値のみ保存する方式。
昨今、あまり選択されない方式。
パスワードを暗号化して保存する方式としては、「秘密鍵・暗号化」と「公開鍵・暗号化」があるが、
ユーザは不特定多数でなく、サーバ機能上で暗号化・復号化を行うだけであるため、「公開鍵・暗号化」を使用する。
ベストプラクティスは、後者。
一般的にはコレ。
を使用してパスワードをハッシュ化してネットワーク上に流す。
OpenID ConnectにおけるJWTの用例などが参考になる。
秘密鍵・暗号化で使用される一方式
鍵ストリーム（擬似乱数列）
秘密鍵・暗号化で使用される一方式
| # | 暗号化モード（暗号利用モード） | 特徴 |
| 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 | などなど他にも沢山ある | ・・・ |
初期化ベクトル（IV: Initialization Vector）
計算の困難性を安全性の根拠とする暗号。
暗号についての概要や体系や、各種の「暗号化アルゴリズム」の詳細については、
説明しないので、これについては、下記サイトや、他の情報源を参照のこと。
具体的な暗号方式の名前ではない。公開鍵暗号が多い。
「デジタル証明書」の検証は、「送信側の公開鍵」を拠り所にしていると言えるが、提供される「送信側の公開鍵」の出所が、正規の出所か、検証できない（場合がある）という問題がある。
このため、この問題を解決するための、「認証局」と呼ばれる、信頼のおける第三者が発行した「デジタル証明書」を使用して「送信側の公開鍵」が信頼できるものであるかを検証する機構がある。
ハッシュとソルト、ストレッチングを正しく理解する：本当は怖いパスワードの話 - ＠IT
http://www.atmarkit.co.jp/ait/articles/1110/06/news154.html
なお、各種の「暗号化アルゴリズム」の「安全性」の問題については、
日々、調査・研究が進められていため、NIST やCRYPTREC などから
公にアナウンスされる情報源を確認のこと。
.NET Framework、.NET Coreのライブラリで提供される署名・暗号化アルゴリズム
