「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。

-[[戻る>暗号化]]

* 目次 [#de7a60fe]
#contents

*概要 [#xce2432b]
-ここでは、暗号化アルゴリズムの概要を解説する。

--[[ハッシュ化>#y6cc34ab]]

--[[暗号化>#xa6356ee]]
---[[秘密鍵・暗号化>#u680ecb7]]
---[[公開鍵・暗号化>#tfda0d72]]
---[[ハイブリッド・暗号化>#z7306cb4]] 

--[[デジタル署名>#leddd7f0]]

--[[認証>#ub86b5f1]]
---[[メッセージ認証符号(MAC)>#w5550a92]]
---[[認証付き暗号（AEDE）>#u0097a82]]

-また、

--暗号の基礎については、[[コチラ>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?SC%EF%BC%9A%E5%AF%BE%E7%AD%96%E6%8A%80%E8%A1%93%20-%20%E6%9A%97%E5%8F%B7]]
--.NETのアルゴリズムは、[[コチラ>.NETの署名・暗号化アルゴリズム]]

>を参照。

*ハッシュ化 [#y6cc34ab]
ハッシュ化とは、「[[ハッシュ関数>#gb8f765f]]」を用いて指定のメッセージの「[[ハッシュ値>#ja806d9a]]」を求める行為である。~

**ハッシュ値 [#ja806d9a]
「メッセージ ダイジェスト」、あるいは単に「ダイジェスト」と呼ぶことがある。~
[[認証>#ub86b5f1]]アルゴリズムの「ダイジェスト[[認証>#ub86b5f1]]」や、「[[チャレンジ＆レスポンス>#d34b7bfa]]認証」で使用されている。

目的によってはハッシュ値のことを「フィンガープリント」、「チェックサム」とも呼ぶ。

**[[ハッシュ関数>http://ja.wikipedia.org/wiki/%E6%9A%97%E5%8F%B7%E5%AD%A6%E7%9A%84%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E9%96%A2%E6%95%B0]] [#gb8f765f]
ココでは、正確には「暗号学的」ハッシュ関数について。

-情報セキュリティ分野で
--[[認証>#ub86b5f1]]
--[[署名>#leddd7f0]]

>など、様々に利用されている。

-また、通常のハッシュ関数としても利用でき、
--ハッシュテーブル（テーブルのキー）
--ダイジェスト、フィンガープリント（[[認証>#ub86b5f1]]）
--データ、ファイルの一意識別、重複検出
--チェックサム（データの誤りを検出）

>などの用途にも利用されている 。

-既成の「ハッシュ関数」を使用した場合、~
以下が満たされているものとして利用できる。

--衝突発見困難性 / 第二原像計算困難性~

---衝突発見困難性~
ハッシュ値を変えずに元のメッセージを改竄することが事実上不可能であること。
ハッシュ値を変えずに元のメッセージを改ざんすることが事実上不可能であること。

---第二原像計算困難性~
同じハッシュ値を持つ2つの元のメッセージを求めること（すりかえ）が事実上不可能であること。

--不可逆性 / 一方向性（原像計算困難性）~
ハッシュ値から元のメッセージを得ることが事実上不可能であること。

#ref(CryptographicHashFunction.png,left,nowrap,暗号学的ハッシュ関数)

-以下の順序で難しい。
>
+不可逆性 / 一方向性（原像計算困難性）
+第二原像計算困難性
+衝突発見困難性

**安全性 [#ff7fd94e]

***キーなし方式・あり方式 [#uc14e156]
「暗号学的ハッシュ関数」には、
-ハッシュ計算用のキーを取れないもの（キーなし方式）と、
-キーを取れるもの（キーあり方式）が存在する。

「暗号学的ハッシュ関数」自体は不可逆であるものの、~
「キーなし方式」の場合、辞書攻撃 により、容易にメッセージが割れる可能性がある。~
このため、辞書攻撃を防ぐ場合、「キーあり方式」を採用する。

***衝突耐性 [#n3f7704b]
「暗号学的ハッシュ関数」を使用する際は、~
最新の「ハッシュの衝突耐性」の情報を入手する事が推奨される。~
これは、例えば、2010/5現在、MD5、SHA-0、SHA-1について~
「強衝突耐性」が突破される脆弱性が発見されているためである。

-＠IT > 第１回　すべてはここから始まった　～　SHA-1 の脆弱化~
http://www.atmarkit.co.jp/fsecurity/rensai/crypt01/crypt01.html
-ITpro > 記者の眼 > APOPのぜい弱性で見えてきたMD5の「ご臨終」~
http://itpro.nikkeibp.co.jp/article/OPINION/20070521/271639/

ただし、「強衝突耐性」が突破されても、直ちに、これらの「暗号学的ハッシュ関数」を用いている~
暗号化通信が盗聴・改竄されたり、電子署名の有効性が無くなったりすると言うわけではない。~
暗号化通信が盗聴・改ざんされたり、電子署名の有効性が無くなったりすると言うわけではない。~
これは、将来的な「弱衝突耐性」の突破を示唆し、「弱衝突耐性」が突破された場合は、~
暗号化通信や電子署名の無改竄性を証明できなくなる。
暗号化通信や電子署名の無改ざん性を証明できなくなる。

-[IT 管理者向け] SHA-1 からの移行を推奨しています~
http://blogs.technet.com/b/jpsecurity/archive/2014/10/15/sha1-migration.aspx
-FAQ: SHA-1 廃止/SHA-2 移行に関するマイクロソフトのポリシー~
http://blogs.technet.com/b/jpsecurity/archive/2015/11/02/faq-microsoft-policy-on-sha1-deprecation.aspx

**[[.NETの暗号学的ハッシュ関数のプロバイダ>.NETの署名・暗号化アルゴリズム#de661712]] [#uc4db25e]

***キーなし方式 [#g774ad06]

-アルゴリズム

--MD
---[[MD5>http://ja.wikipedia.org/wiki/MD5]]
---[[RIPEMD160>https://ja.wikipedia.org/wiki/RIPEMD]]

--[[SHA>http://ja.wikipedia.org/wiki/SHA]]
---[[SHA1>https://ja.wikipedia.org/wiki/SHA-1]]
---[[SHA256>https://ja.wikipedia.org/wiki/SHA-2]]
---SHA384
---SHA512

-[[.NETの暗号学的ハッシュ関数（キーなし方式）>.NETの署名・暗号化アルゴリズム#l1894cde]]

***キーあり方式 [#kdb48f23]

-アルゴリズム~
≒[[メッセージ認証符号（MAC）>#j74d157f]]

-[[.NETの暗号学的ハッシュ関数（キーあり方式）>#u4912a9a]]

*暗号化 [#xa6356ee]
暗号化の方式には、大きく分けて、
-[[秘密鍵・暗号化>#u680ecb7]]~
暗号化と復号が同じ処理であるところから、「対称アルゴリズム」とも呼ばれる。
-[[公開鍵・暗号化>#tfda0d72]]~
暗号化と復号が違う処理であるところから、「非対称アルゴリズム」とも呼ばれる。

の２つの方式がある。

以下の表に「[[秘密鍵・暗号化>#u680ecb7]]」と、「[[公開鍵・暗号化>#tfda0d72]]」との比較を示す。

なお、両者のメリット・デメリットを考慮し、両者を組み合わせたハイブリッドの方式もある。~
これについては、「[[ハイブリッド・暗号化方式>#z7306cb4]]」の項にて説明する。

#ref(ComparisonOfEncryptionScheme.png,left,nowrap,暗号化方式の比較)

-※1 : 「[[秘密鍵・暗号化>#u680ecb7]]」は、暗号化と復号化に使用する鍵が、~
　　同一の秘密鍵であることから、「共通鍵・暗号化方式」とも呼ばれる。

-※2 : 「[[秘密鍵・暗号化>#u680ecb7]]」の鍵はパスワードのようなもので、~
　　基本的に相手毎に、この秘密鍵（パスワード）を変えることが望ましい。~
　　従って、相手が増えるほど管理する秘密鍵が増える。~
　　ただし、自分のために暗号化し、自分だけが復号化する場合は、秘密鍵は１つでも良い。

-※3 : アルゴリズムが非対称であると、数学的に難しい処理が多く、高速での処理が難しくなるため。

**秘密鍵・暗号化 [#u680ecb7]

***概要 [#j29c91c7]
-「[[秘密鍵・暗号化>#u680ecb7]]」は、
--秘密鍵を使用して暗号化・復号化を行う。
--秘密鍵として、任意のキー（パスワード）を使用できる。

-この方式は、~
秘密鍵の受け渡しと、管理が困難となるため、~
不特定多数のユーザとネットワーク越しの~
情報受け渡しを行うC/Sシステムには使用されない。

-方式に「[[ストリーム暗号>#k3cd4c1b]]」、「[[ブロック暗号>#oda3635b]]」がある。

***アルゴリズム [#qc8a3968]
-[[DES>http://ja.wikipedia.org/wiki/DES_%28%E6%9A%97%E5%8F%B7%29]]
-[[RC2>http://ja.wikipedia.org/wiki/RC2]]
-[[Rijndael>http://ja.wikipedia.org/wiki/AES%E6%9A%97%E5%8F%B7]]
-[[3DES>http://ja.wikipedia.org/wiki/%E3%83%88%E3%83%AA%E3%83%97%E3%83%ABDES]]

***鍵の数 [#x79daa8d]
-パス数の算出にはPMPの[[コミュニケーション・チャネル式>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?PMP%EF%BC%9A%E8%A9%A6%E9%A8%93%20-%20%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF#o149b4de]]が使える。

-具体的には、ｎ人で、（ｎ（ｎ－１））÷２個の鍵が必要になる

***[[.NETの秘密鍵・暗号化方式のプロバイダ>.NETの署名・暗号化アルゴリズム#r45cd534]] [#l163d171]

**公開鍵・暗号化 [#tfda0d72]

***概要 [#cb3872e2]
-「[[公開鍵・暗号化>#tfda0d72]]」は、秘密鍵・公開鍵のキー・ペアを生成する。

-この方式は、~
公開鍵で暗号化したものは、秘密鍵でしか復号できないと言う性質を利用して、~
不特定多数のユーザとネットワーク越しの情報受け渡しを行うC/Sシステムに使用される。

***処理シーケンス [#c6b9f1bd]
-処理シーケンスは次のようになる。
>
+送信側は、「受信側の公開鍵」を取得する。
+送信側は、平文を「受信側の公開鍵」で暗号化する。
+上記、暗号化された平文を送付する。
+受信側は、平文を、「受信側の秘密鍵」で復号化する。

-以下の図に、その処理方式の概要図を示す。
#ref(PublicKeyEncryptionSchemes.png,left,nowrap,公開鍵・暗号化方式)

***アルゴリズム [#w5303ada]
-[[RSA>#n94858e7]]

***鍵の数 [#t98fdeab]
-公開鍵の場合は、各人が秘密鍵公開鍵のペアを持てばイイ
-公開鍵の場合は、各人が秘密鍵・公開鍵のペアを持てばイイ
-具体的には、ｎ人で、２ｎ個の鍵が必要になる。


***[[.NETの公開鍵・暗号化方式のプロバイダ>.NETの署名・暗号化アルゴリズム#q04bc939]] [#ud11fac2]
.NETにて提供されるRSACryptoServiceProviderを使用した場合、
-同じ公開鍵を使用しても暗号化情報は可変になるが、~
同じ秘密鍵で復号化が可能であるので、リプレイ攻撃の対象になる。
-このため、公開鍵・秘密鍵のキー・ペアを可変にするか、~
チャレンジを加えるなどの実装を追加する必要がある。

なお、リプレイ攻撃とは、ユーザがログインするときにネットワークを流れる電文を盗聴し、~
これを自分の送信する電文として利用することでシステムへ不正にログインしようとする行為を指す。

**ハイブリッド・暗号化（キー交換） [#z7306cb4]
[[秘密鍵・暗号化>#u680ecb7]]、[[公開鍵・暗号化>#tfda0d72]]の両者のメリットとデメリットを考慮し、~
組み合わせた「ハイブリッド・暗号化方式」もある。~
一般的には、[[アリスとボブ - Wikipedia>https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%AA%E3%82%B9%E3%81%A8%E3%83%9C%E3%83%96]]で知られている。

***処理シーケンス [#r53b0d97]
-処理シーケンスは次のようになる。
>
+送信側は、「受信側の公開鍵」を取得する。
+送信側は、「送信側の秘密（共通）鍵」を、「受信側の公開鍵」で暗号化する。
+上記、暗号化された「送信側の秘密（共通）鍵」を送付する。
+受信側は、「送信側の秘密（共通）鍵」を、「受信側の秘密鍵」で復号化する。
+送信側は、平文を「送信側の秘密（共通）鍵」で暗号化する。
+上記、暗号化された平文を送付する。
+受信側は、平文を、「送信側の秘密（共通）鍵」で復号化する。

-以下の図に、その処理方式の概要図を示す。~
※「[[秘密鍵・暗号化>#u680ecb7]]」と「[[公開鍵・暗号化>#tfda0d72]]」の鍵を区別しやすくするように、~
ここでは、「[[秘密鍵・暗号化>#u680ecb7]]」の秘密鍵を、秘密（共通）鍵と記述した。
#ref(HybridEncryptionScheme.png,left,nowrap,ハイブリッド・暗号化方式)

--「[[公開鍵・暗号化>#tfda0d72]]」で「送信側の秘密（共通）鍵」を共有し、~
平文自体は速度の速い「[[秘密鍵・暗号化>#u680ecb7]]」で暗号化・復号化するため、~
「安全性」を落とさずに、処理速度を稼ぐことができる。

--また、「送信側の秘密（共通）鍵」（セッション鍵）をセッション毎に変更すれば、~
万一共通鍵での暗号部分が解読されても短い時間しかクラッキングできなくなる。

-なお、SSL暗号化なども、この「ハイブリッド・暗号化方式」を採用している。

--ThinkIT > サーバ構築・運用 >~
いまさら聞けないApache ～ Webサーバ構築のキソ > 第6回 : SSLの基本を押さえる~
http://thinkit.co.jp/free/article/0706/3/6/

***PFS（Perfect Forward Security） [#j506d7c6]
-暗号文とその暗号文を複合するための秘密鍵が両方漏洩しても、~
暗号文を複合できない、というカギ交換に関する概念

-PFSを実現可能にするためのアルゴリズム
--DHE：ディフィー・ヘルマン鍵共有
--ECDHE：楕円曲線ディフィー・ヘルマン鍵共有

-SSL/TLSでは、証明書と組み合わせた以下の何れかの方式を使う。
--DHE-RSA~
DHEとRSA証明書の組み合わせ
--DHE-DSA~
DHEとDSA証明書の組み合わせ
--ECDHE-RSA~
ECDHEとRSA証明書の組み合わせ
--ECDHE-ECDSA~
ECDHEと楕円曲線DSA証明書の組み合わせ

-公開鍵は
--何かしらの証明を付けた静的なものであっても、
--一時的なもの（ephemeral、この場合特にDHE、ECDHEと略記される）

>であってもかまわない。

***アルゴリズム [#uc9ab978]
-[[RSA>#n94858e7]]
-[[ECDH>#j46c8e11]]

***[[.NETの公開鍵・暗号化方式のプロバイダ>.NETの署名・暗号化アルゴリズム#q04bc939]] [#ud11fac2]

*デジタル署名 [#leddd7f0]

**概要 [#udf15110]
「デジタル署名」は、元となるメッセージのハッシュを秘密鍵で暗号化したものである。

送信元が、この「デジタル署名」を、元となるメッセージと同梱して送付することにより、~
送信先は、元となるメッセージの正当性を（＝ 改ざんされていない事を）検証できる。

**処理シーケンス [#n89c5005]
-処理シーケンスは次のようになる。
>
+送信側は、「メッセージ」から「メッセージのハッシュ」を求め、~
これを「送信側の秘密鍵」で暗号化することで、「デジタル署名」を生成する。
+送信側は、「メッセージ」、「デジタル署名」を送付する。
+受信側は、「デジタル署名」を、「送信側の公開鍵」を使用して、~
復号化することで、「メッセージのハッシュ」を求め、メッセージを検証する。

-以下の図に「デジタル署名」の処理方式の概要図を示す。
#ref(DigitalSignature.png,left,nowrap,デジタル署名)

-このことから、「デジタル署名」は、~
「[[公開鍵・暗号化>#tfda0d72]]」とは逆に「非対称アルゴリズム」を~
使用していることが分かる（秘密鍵で暗号化し、公開鍵で復号化）。

**アルゴリズム [#sddeda05]
-[[RSA>#n94858e7]]
-[[DSA>#j453a343]]
-[[ECDSA>#j46c8e11]]

**[[.NETのデジタル署名のプロバイダ>.NETの署名・暗号化アルゴリズム#lf5eb161]] [#za613abc]
「デジタル署名」では、秘密鍵・公開鍵のキー・ペアを、プロバイダを使用して生成する必要がある。

*認証 [#ub86b5f1]

**メッセージ認証符号（MAC） [#w5550a92]

***概要 [#c1312f41]
-・・・
--MAC(メッセージ認証コード)とは - CubicLouve~
https://spring-mt.hatenablog.com/entry/2017/08/20/202708
--メッセージ認証符号 - Wikipedia~
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
---メッセージ認証符号 = MAC: Message Authentication Code
---メッセージ認証完全性コード = MAIC: Message Authentication and Integrity Code

-暗号学的ハッシュ関数との違い~
MAC関数は選択平文攻撃における存在的偽造に対して耐性がなければならない。~
つまり、共通鍵を持ちMAC関数を計算できる"復号オラクル"にアクセスできる~
攻撃者が、任意に選んだメッセージに対応するMACを取得できたとしても、~
他の（"復号オラクル"に問い合わせていない）メッセージに対するMACを~
"復号オラクル"に対して問い合わせずに計算で求めることが計算量的に困難でなければならない。

-デジタル署名との違い
--MAC値の生成と検証には同じ鍵（共通鍵暗号）が使われるので、~
送信者と受信者は通信を行う前に鍵を共有しておく必要がある。
--また、共通鍵暗号であるために、MACによって認証されるメッセージは、~
偽造ではなく送信者が作成し送信したという確証、つまり否認不可性をもたない。~
なぜなら、MAC値を検証する利用者（メッセージの受信側）は、~
通信の相手から受け取ったメッセージではなく、受信側で捏造したメッセージ~
についても共通鍵を使ってMAC値を生成することができるからである。

***処理シーケンス [#be058380]
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用の共通鍵を、~
[[ハイブリッド・暗号化>#z7306cb4]]の[[ECDH>#j46c8e11]]で生成された共通鍵からハッシュ関数によって生成される。

***アルゴリズム [#j74d157f]
-概要~
MACアルゴリズムは他の暗号プリミティブから構築できる。
--ハッシュ関数（キーあり方式）を使う方式（HMAC、3DES）
--[[ブロック暗号>#oda3635b]]アルゴリズムを使う方式（OMAC/CMAC、CBC-MAC、PMAC）

-HMAC - Wikipedia~
https://ja.wikipedia.org/wiki/HMAC

--HMAC (Hash-based Message Authentication Code) とは、
---[[メッセージ認証符号 (MAC; Message Authentication Code)>#w5550a92]]の一つ
---ハッシュ関数に基づくメッセージ認証符号アルゴリズム

--種類
---HMAC-MD5
---HMAC-Ripemd-160
---HMAC-SHA1
---HMAC-SHA256
---HMAC-SHA384
---HMAC-SHA512

-CMAC - Wikipedia~
https://ja.wikipedia.org/wiki/CMAC

--CMAC (Cipher-based Message Authentication Code) とは、
---[[メッセージ認証符号 (MAC; Message Authentication Code)>#w5550a92]]の一つ
---ブロック暗号に基づくメッセージ認証符号アルゴリズム

--種類
---CBC-MAC
---CFB, OFB-MAC等は無い。

-その他
--MAC3DES

-RFC
--HMAC: Keyed-Hashing for Message Authentication~
https://www.ietf.org/rfc/rfc2104.txt
--RFC 1851 - The ESP Triple DES Transform~
https://tools.ietf.org/html/rfc1851

***APIインターフェイス [#m7ae514c]
-入力として共通鍵と認証すべき任意長のメッセージを受け取る。

-MAC（「タグ」とも呼ばれる）を出力する。~
MAC値は（、共通鍵をもつ）、検証者がメッセージの内容の変化を~
検出できるようにして、メッセージの完全性を保護し、認証する。

***[[.NETのメッセージ認証符号（MAC）のプロバイダ>.NETの署名・暗号化アルゴリズム#x4fe1902]] [#u4912a9a]

-参考
--MAC、ハッシュ、および署名 - UWP app developer | Microsoft Docs~
https://docs.microsoft.com/ja-jp/windows/uwp/security/macs-hashes-and-signatures#message-authentication-codes-macs

**認証付き暗号（AEAD） [#u0097a82]

***概要 [#xc9201d0]
-・・・
--MAC(メッセージ認証コード)とは - CubicLouve~
https://spring-mt.hatenablog.com/entry/2017/08/20/202708
>認証付き暗号(Authenticated Encryption with Associated Data)

--認証付き暗号 - Wikipedia~
https://ja.wikipedia.org/wiki/%E8%AA%8D%E8%A8%BC%E4%BB%98%E3%81%8D%E6%9A%97%E5%8F%B7
---AE: Authenticated Encryption
---AEAD: Authenticated Encryption with Associated Data

-説明
--Authenticated Encryption with Associated Dataを略してAEADとも呼ばれる。
---MACと対称暗号を組み合わせて、機密性(暗号)、認証・正真性(MAC)を満たす仕組み。
---AEAD(認証付き暗号)では不適切に細工された暗号文を識別(MACの認証と正真性)して~
復号を拒否することができるため、選択暗号文攻撃に対して安全になる。

--データの秘匿性、完全性、および認証性を同時に提供する[[暗号化モード>#s2956a2c]]で、復号すると同時に完全性も検証される。~
＝秘匿性と完全性の保護に加えて、認証付き暗号は平文既知性 (PA: plaintext awareness) を備えており、選択暗号文攻撃に対して安全である。
---この種の攻撃で敵は、よく考えられた暗号文を "復号オラクル" に渡して復号結果を分析することで、暗号システムの攻略ヒントを得ようとする。
---認証付き暗号システムは不適切に細工された暗号文を識別して復号を拒否することができる。
---適切に暗号化アルゴリズムを使って生成（≒平文を既に知っている）しない限り暗号文の復号要求を防ぐということである。
---適切に実装されていれば、これにより攻撃者が既に知っている以上の有用な情報を復号オラクルで取り出せないようになる。

--認証付き暗号対応のクラスライブラリを使用すれば、こうした特性がまとめて提供される。

--秘匿用モードと認証用モードを安全に合成するのが困難であろうとの報告により、AE の必要性が明らかになった。

***処理シーケンス [#lf0ac4fc]
-共通鍵[[ブロック暗号>#oda3635b]]で使うための認証付き暗号専用のモードも数多く開発されているが、~
一般的に認証付き暗号は、以下要件を満たす暗号システムと[[メッセージ認証符号（MAC）>#w5550a92]]を組み合わせて構成する。~
--暗号システム：選択平文攻撃のもとで強秘匿性を有する必要がある。
--[[MAC関数>#w5550a92]]：選択メッセージ攻撃のもとで偽造不可でなければならない。

-認証付き暗号の手法~
Bellare and Namprempre (2000) はこうしたプリミティブの組み合わせを三通り考察し、~
暗号と [[MAC>#w5550a92]] 双方の関数が必要な性質を満たす場合は、メッセージを暗号化してから~
暗号文に [[MAC>#w5550a92]] を計算することで適応的選択暗号文攻撃に対し安全であることを実証した。

--Encrypt-then-MAC (EtM)~
https://ja.wikipedia.org/wiki/%E8%AA%8D%E8%A8%BC%E4%BB%98%E3%81%8D%E6%9A%97%E5%8F%B7#/media/File:Authenticated_Encryption_EtM.png

--Encrypt-and-MAC (E&M)~
https://ja.wikipedia.org/wiki/%E8%AA%8D%E8%A8%BC%E4%BB%98%E3%81%8D%E6%9A%97%E5%8F%B7#/media/File:Authenticated_Encryption_EaM.png

--MAC-then-Encrypt (MtE)~
https://ja.wikipedia.org/wiki/%E8%AA%8D%E8%A8%BC%E4%BB%98%E3%81%8D%E6%9A%97%E5%8F%B7#/media/File:Authenticated_Encryption_MtE.png

***アルゴリズム [#i96cb450]
6種類の異なるモードが、~
ISO/IEC 19772:2009 によって標準化され、~
さらにNISTによって開発がすすめられた。

-OCB 2.0
-Key Wrap
-EAX
-Encrypt-then-MAC (EtM)

-Counter with CBC-MAC - Wikipedia~
https://ja.wikipedia.org/wiki/Counter_with_CBC-MAC

--RFC

---RFC 3610 - Counter with CBC-MAC (CCM)~
https://tools.ietf.org/html/rfc3610
---RFC 4309 - Using Advanced Encryption Standard (AES) CCM Mode~
with IPsec Encapsulating Security Payload (ESP)~
https://tools.ietf.org/html/rfc4309
---RFC 6655 - AES-CCM Cipher Suites for Transport Layer Security (TLS)~
https://tools.ietf.org/html/rfc6655

-Galois/Counter Mode - Wikipedia~
https://ja.wikipedia.org/wiki/Galois/Counter_Mode

--RFC

---RFC 5288 - AES Galois Counter Mode (GCM) Cipher Suites for TLS~
https://tools.ietf.org/html/rfc5288
---RFC 5647 - AES Galois Counter Mode for the Secure Shell Transport Layer Protocol~
https://tools.ietf.org/html/rfc5647

--その他

---本当は怖いAES-GCMの話 - ぼちぼち日記~
http://d.hatena.ne.jp/jovi0608/20160524/1464054882
---C#:AES GCMでコンテンツ暗号~
https://qiita.com/hidelafoglia/items/d12550c8ffe6eca993c8
---GoでAESアルゴリズム(GCMモード)を使った実装をする~
https://qiita.com/ken5scal/items/da387d6db8b8308474e6

***APIインターフェイス [#gcf1a841]
AEADの典型的な APIインターフェイス は次のような関数を提供する:

-暗号化
--入力
---鍵
---平文
---追加認証データ（AAD）~
アルゴリズムによっては必要になる。~
認証や完全性保護のためにあり、~
暗号化はされないが認証保護の対象。

--出力
---暗号文
---認証タグ（[[MAC>#w5550a92]]）、

-復号化
--入力
---鍵
---暗号文
---認証タグ（[[MAC>#w5550a92]]）
---追加認証データ（AAD）

--出力
---平文
---平文が、認証タグ（[[MAC>#w5550a92]]）、追加認証データ（AAD）に合致しない場合はエラー

***.NETの認証付き暗号のプロバイダ [#n967296a]
-Security.Cryptography.AuthenticatedAes
--昔、[[codeplex>.NETの署名・暗号化アルゴリズム#dc18d317]]で提供されていたSecurity.Cryptography.AuthenticatedAes辺りを使用可能。~
--ただし、現在は、GitHubに移動されているが、メンテナンスされておらず、[[.NET Core]]対応がされていない。

-BouncyCastle
--色々調べると、BouncyCastleに行きつく。
--参考：https://github.com/OpenTouryoProject/OpenTouryo/tree/develop/root/programs/CS/Frameworks/Infrastructure/Public/Security/Aead

*その他 [#pf7ca8aa]

**パスワードを格納する方式 [#nf98d8cd]
WebサイトのForms認証などを実装する場合、[[ハッシュのみ保管>#n6bb6738]]が一般的。

***ハッシュのみ保管 [#n6bb6738]
パスワードのハッシュ値のみ保存する方式。

-メリット
--[[暗号学的ハッシュ関数>暗号化アルゴリズム#gb8f765f]]の「不可逆性」「衝突困難性」を利用する。
--パスワードの代わりハッシュ値のみを保存すると鍵管理の煩わしさがない。

-デメリット~
パスワードを保存していないため、

--パスワード・リマインダを実装できない~
（昨今、パスワード・リセットが一般的で、実装不要）。

--パスワードの平文が取得できない。

---「[[チャレンジ＆レスポンス>#d34b7bfa]]」方式を併用できない。

---パスワードの保存方法の変更が難しくなる。~
（次回認証時のパスワード入力を待って変更することは可能）

※ [[ベスト・プラクティス>#i07ea967]]

***暗号化して保管 [#of9c297e]
昨今、あまり選択されない方式。

パスワードを暗号化して保存する方式としては、「[[秘密鍵・暗号化>#u680ecb7]]」と「[[公開鍵・暗号化>#tfda0d72]]」があるが、~
ユーザは不特定多数でなく、サーバ機能上で暗号化・復号化を行うだけであるため、「[[公開鍵・暗号化>#tfda0d72]]」を使用する。

***ベスト・プラクティス [#i07ea967]
-[[ハッシュのみ保管>#n6bb6738]]の
--「[[キーあり方式>#kdb48f23]]」
--「[[キーなし方式>#g774ad06]]」＋ソルト、ストレッチング

>ベストプラクティスは、後者。

-ソルト、ストレッチング

--ソルトの意味~
同じパスワードでも、ユーザーごとに異なるソルトを使い異なるハッシュ値にできる。
---[[レインボー・テーブル>#j2295dce]]探索を妨害する。
---ソルトはハッシュ値とともに保存する。

--ストレッチングの意味
---高速なハッシュを繰り返し用いることで速度を遅くする。
---これにより、オフライン総当たり攻撃を妨害する。

**ネットワークへパスワードを流す方式 [#yeb0589d]
-セキュアな認証基盤では、ネットワーク上に流すパスワードは、平文以外で流す必要がある。
-パスワードを平文以外でネットワーク上に流す方式として以下の方式が考えられる。以下、それぞれの方式の詳細について説明する。

***HTTPS [#m1514a5d]
一般的にはコレ。

-平文で送信される基本認証、Forms認証のユーザアカウントの暗号化
-HTTPSは、共通鍵が通信セッション 毎に可変となるため、リプレイ攻撃 に対しても対処できる。

***チャレンジ＆レスポンス [#d34b7bfa]
[[NTLM>認証基盤#zb3340de]]や[[CHAP>ネットワークの基礎編#sa5b6b1b]]などで採用されている方式。

-「暗号学的ハッシュ関数」（[[キーなし方式>#g774ad06]]）では、リプレイ攻撃の対象となり得るため、
--チャレンジ（認証する側が認証される側に送信する乱数とID）と、
--「暗号学的ハッシュ関数」（キーあり方式）

>を使用してパスワードをハッシュ化してネットワーク上に流す。

-可変のハッシュ（レスポンス）を元に認証処理を遂行するため、~
認証基盤側は、ユーザ アカウント（パスワード）を平文で保持している必要がある。

***公開鍵・暗号化 [#k6330e85]
-「[[公開鍵・暗号化>#tfda0d72]]」では、同じ公開鍵を使用しても暗号化情報は可変になるが、~
同じ秘密鍵で復号化可能であることが確認でき、結局、リプレイ攻撃の対象となり得る。

-このため、「[[公開鍵・暗号化>#tfda0d72]]」を使用してパスワードを暗号化してネットワーク上に流す場合、~
元となるメッセージにチャレンジを加え暗号化するなどの実装を追加する必要がある（[[ハイブリッド・暗号化>#z7306cb4]] ）。

**ネットワークへ認証チケットを流す方式 [#g187e834]
[[OpenID Connect]]における[[JWT]]の用例などが参考になる。

*暗号化の詳細 [#g967e74c]

**初期化ベクトル [#z3a67f9f]
初期化ベクトル（IV: Initialization Vector）

-[[ストリーム暗号>#k3cd4c1b]]~
鍵ストリーム（擬似乱数列）の生成に利用する。
（IVを、）鍵ストリーム（擬似乱数列）の生成に利用する。

-[[ブロック暗号>#oda3635b]]

-[[ブロック暗号>#oda3635b]]~
（IVを、）
--最初のブロックに使用されるベクトル値とする（＝共通鍵）。
--[[暗号化モード>#s2956a2c]]で前の平文ブロックの結果を次の平文に使用する。
--このときの最初のブロックに使用されるベクトル値が初期化ベクトル。

**ストリーム暗号 [#k3cd4c1b]

***概要 [#x0ac7fa2]
-ビット、バイト、文字毎に処理
-[[ブロック暗号>#oda3635b]]より仕組みが単純で高速
-暗号化してもデータサイズが変化しない（通信処理に適する）。

***詳細 [#sbebd981]
鍵ストリーム（擬似乱数列）
-を、共通鍵や[[初期化ベクトル>#z3a67f9f]]をシード（初期値）として生成。
-と、平文 / 暗号文との排他的論理和で暗号化 / 復号化する。

***アルゴリズム [#t41da36e]
-KCipher-2~
九州大学とKDDI研究所により共同開発

-Salsa20~
ダニエル・バーンスタインによって開発（パブリック・ドメイン）

-RC4~
SSLやWEPなどで広く使われているが、危殆化が進んでいる。

-MUGI~
日立製、推奨暗号リスト→推奨候補暗号リスト
日立製、推奨暗号リスト → 推奨候補暗号リスト

-A5/1~
GSM携帯電話規格で利用されていたが、~
リエンジで脆弱性が見つかっている。

**ブロック暗号 [#oda3635b]

***概要 [#hca1fd38]
-ブロック毎に処理
-[[ストリーム暗号>#k3cd4c1b]]より仕組みが複雑で低速
-空きはパディングするのでデータサイズが増加する。
-そのままでは、暗号強度が弱いので、鍵ストリーム（擬似乱数列）代替として、~
前ブロック値を平文 / 暗号文との排他的論理和に使用する[[暗号化モード>#s2956a2c]]がある。

***詳細 [#m6a7f28d]
-通常、暗号化は鍵のサイズと同じバイト長を１ブロックとして暗号化する。~
1024ビットの鍵ならば = 1024 / 8 = 128バイトを１ブロックとして暗号化する。

-アルゴリズムによって、以下が、決まっていることがある。
--ブロック長（固定ブロック長、可変ブロック長）
--[[暗号化モード（暗号利用モード）>#s2956a2c]]

***アルゴリズム [#g3177b42]
-AES~
DESの後継

-DES, DES-X, 3DES
--DES : 1977以降の米国政府の標準
--DES-X : 鍵長のみを長くした。
--3DES : DESを3重に適用した。

-RC2, RC5, RC6~
ロナルド・リベストが設計

-IDEA~
スイス工科大学のXuejia Laiにより開発。

-Camellia~
NTTと三菱電機が開発。

-CAST-128, CAST-256~
設計者の頭文字を取ってCAST、数字は鍵長（最大値）

-, etc.

***処理シーケンス [#s7f61245]
-暗号化
>
+アルゴリズムに対応した[[ブロック長>#n198a397]]に分割する。
+[[ブロック長>#n198a397]]に満たない部分を[[パディング方式>#n433994e]]で補完する。
+暗号鍵を用いてアルゴリズムで暗号化する。
+分割されたデータを結合する。

-復号化
>
+アルゴリズムに対応した[[ブロック長>#n198a397]]に分割する。
+暗号鍵を用いてアルゴリズムで復号化する。
+補完された部分を[[パディング方式>#n433994e]]で除去する。
+分割されたデータを結合する。

***暗号化モード（暗号利用モード） [#s2956a2c]
-ブロック分割のメカニズム
-分割モードによっては[[初期化ベクトル>#z3a67f9f]]が必要になる。

-[[認証>#ub86b5f1]]用の利用モード、秘匿用の利用モードとがある。
--[[認証>#ub86b5f1]]用の利用モード
|#|||h
|1|CCM|Counter with CBC-MAC|
|2|OCB|Offset CodeBook|
|3|XCBC|eXtended Ciphertext Block Chaining|
|4|XCBC-MAC||

--秘匿用の利用モード
|#|暗号化モード（暗号利用モード）|特徴|h
|1|ECB: Electronic CodeBook&br;暗号ブックモード|・単純にブロックに分割しそのまま暗号化するため、[[初期化ベクトル>#z3a67f9f]]を必要としない。&br;・鍵と暗号対象データが同じであれば、同じ暗号データになるため、暗号文一致攻撃、暗号文改ざん攻撃に弱いという問題がある。|
|2|CBC: Cipher Block Chaining&br;暗号文ブロック連鎖モード|・最初のブロックについては最後のブロック or [[初期化ベクトル>#z3a67f9f]]と暗号対象データをXOR計算した結果を暗号化する。&br;・次のブロックについては、前の暗号化ブロックとそのブロックをXOR計算した結果を暗号化する。&br;・[[ブロック暗号>#oda3635b]]を[[ストリーム暗号>#k3cd4c1b]]のように利用するため、元のデータが部分的に同じで、鍵が同一でも一意の暗号データになり難い。|
|3|CFB: Cipher-FeedBack&br;暗号フィードバックモード|CBCと比較すると、初回のXORには暗号化したVIを使用する。&br;初回のブロックは、VIとのXOR処理のみの未暗号化ブロックで、&br;以降のブロックは、前のブロックを暗号化したブロックとそのブロックをXOR計算する。|
|4|OFB: Output FeedBack&br;出力フィードバックモード|・[[初期化ベクトル>#z3a67f9f]]を暗号化し、それをまた暗号化し、次々と乱数を生成する。&br;・その乱数列を XOR 演算によって平文に重ね合わせ暗号化処理を行う。&br;・[[ブロック暗号>#oda3635b]]を[[ストリーム暗号>#k3cd4c1b]]のように利用するため、元のデータが部分的に同じで、鍵が同一でも一意の暗号データになり難い。|
|5|などなど他にも沢山ある|・・・|

-参考
--暗号利用モード - Wikipedia~
https://ja.wikipedia.org/wiki/%E6%9A%97%E5%8F%B7%E5%88%A9%E7%94%A8%E3%83%A2%E3%83%BC%E3%83%89

***パディングモード（パディング方式） [#n433994e]
-[[ブロック分割>#n198a397]]する時に割り切れない場合は、パディングで穴埋めする。
-[[ブロック分割>#n198a397]]する時に~
割り切れない場合は、パディングで穴埋めする。

-パディング方式の種類

--NoPadding~
パディングしない

--ZeroBytePadding
---NULLバイト(0x00)でパディング
---元データにNULLバイトが含まれていない場合でないと使えない

--[[PKCS>証明書#kf9dd196]]#5 Padding (RFC1423)
---ブロック長に満たないサイズの値を表すバイト値で足りない分を埋める
---ブロック長ぴったりな場合は1ブロック分丸ごとパディングされる

--[[PKCS>証明書#kf9dd196]]#7 Padding

--PKCS#1 v1.5 Padding

--Optimal Asymmetric Encryption Padding（OAEP）
---日本語で、最適非対称暗号化パディング~
---[[PKCS>証明書#kf9dd196]]#1 に定義されているOAEPWith<digest>And<mgf>Padding
---OAEPはRSAと組み合わせることが多く、その場合はRSA-OAEPと呼ばれる。

--その他
---SSL3Padding
---ISO10126Padding
---ISO10126d2Padding
---ISO7816d4Padding
---TBCPadding
---X9.23Padding

-参考
--Wikipedia
---Padding (cryptography)~
https://en.wikipedia.org/wiki/Padding_(cryptography)
---Optimal Asymmetric Encryption Padding~
https://ja.wikipedia.org/wiki/Optimal_Asymmetric_Encryption_Padding

*公開鍵・暗号化の詳細 [#ba2b3fe6]
計算の困難性を安全性の根拠とする暗号。

**アルゴリズム [#ob238f02]

***RSA [#n94858e7]
-RSA : Rivest-Shamir-Adleman cryptosystem

-設計者の頭文字を取ってRSA

-暗号化とデジタル署名に利用できる。

-素因数分解問題（RSA暗号、Rabin暗号）を利用~
巨大な素数同士をかけ合わせた整数の素因数分解の困難性。

***DSA [#j453a343]
-DSA : Digital Signature Algorithm

-デジタル署名に利用でき、~
暗号化には利用できない。

-[[離散対数問題>#t96a2968]]（ElGamal暗号）を利用

***ECC（ECDSA, ECDH） [#j46c8e11]
-ECC : Elliptic Curve Cryptography

-楕円曲線暗号
--楕円曲線を利用した暗号方式の総称
--楕円曲線上の[[離散対数問題>#t96a2968]]の困難性に依る。

--ECDSA

---ECDSA : Elliptic Curve DSA

---楕円曲線DSA (ECDSA)

---DSAを楕円曲線上で定義

---デジタル署名に利用でき、~
暗号化には利用できない。

--ECDH

---ECDH : Elliptic curve Diffie–Hellman key exchange

---[[DH鍵共有（交換）>#w2cf2dea]]を楕円化

---DH判定問題（Cramer-Shoup暗号）~
(ga,gb)が与えられて、gabを求める問題の困難性に依る。

---暗号化には利用できる（共通鍵の共有のための暗号化）。

---以下の二種類のECDHがある。~
・ephemeral-ephemeral : ECDHE~
・ephemeral-static : ECDH-ES~

**離散対数問題 [#t96a2968]

***概要 [#n7d0b136]
-２つのノードは素数 p と定数 g (p より小さい)を共有する。

-ある整数 x に対して g の x 乗を p で割った余りを y とする。

-この際の、
-この際の、離散対数（x, y）
--y（≒ 公開鍵）から
--x（≒ 秘密鍵）を

>求める困難性に依る。
>求める困難性に依る（素数 pが大きい値になればなるほど困難になる）。

***詳細 [#ib5f6e1d]
-シーケンス

--２つのノードA、Bは素数 p と定数 g (p より小さい)を共有する。
--２つのノードA（アリス）、ノードB（ボブ）は~
素数 p と定数 g (p より小さい)を共有する。

--ノードAは、
--ノードA（アリス）は、
---秘密鍵 x を生成し、(g^x) / p ... y を計算する。
---公開鍵 y をノードBに送信する

--ノードBは、
--ノードB（ボブ）は、
---秘密鍵 x' を生成し、(g^x') / p ... y' を計算する。
---公開鍵 y' をノードAに送信する

--これにより、公開鍵の共有ができたので、~
コレを使用して以下の共通鍵 a の共有を行う。
 a = y'^x mod p = y^x' mod p
コレを使用して以下の共通鍵 a の共有を行う。~
a = y'^x mod p = y^x' mod p

-具体的な数値の例

--前提
---p = 41
---g = 2

--ノード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
--- y'^x mod p = 4^15 mod 41 = 40
--- y^x' mod p = 9^22 mod 41 = 40
---ノードA~
a = y'^x mod p = 4^15 mod 41 = 40
---ノードB~
a = y^x' mod p = 9^22 mod 41 = 40

**DH鍵共有（交換） [#w2cf2dea]
-ディフィー・ヘルマン鍵共有
-Diffie–Hellman key exchange

-事前の秘密の共有無しに、~
盗聴の可能性のある通信路を使って、~
暗号鍵の共有を可能にする暗号プロトコル

-双方が[[公開鍵>#bd030d3d]]を使用して、[[共通鍵>#bd030d3d]]を共有する。

-公開鍵の方式としては、[[離散対数問題>#t96a2968]]を使用する。

-楕円化したものを、
>[[楕円曲線DH鍵共有（Elliptic curve Diffie–Hellman key exchange, ECDH）>#j46c8e11]]

>と言う。

*参考 [#obc20caf]
暗号についての概要や体系や、各種の「暗号化アルゴリズム」の詳細については、~
説明しないので、これについては、下記サイトや、他の情報源を参照のこと。

-[暗号化]ブロック暗号とは(AES/DES/Blowfish PKCS5Padding ECB/CBC IV) - [技術資料 + 技術資料] ぺんたん info~
-[暗号化]ブロック暗号とは~
(AES/DES/Blowfish PKCS5Padding ECB/CBC IV)~
[技術資料 + 技術資料] ぺんたん info~
http://pentan.info/doc/block_cipher.html

-電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）~
平成２５年３月１日 総 務 省 経済産業 省~
-電子政府における調達のために~
参照すべき暗号のリスト（[[CRYPTREC>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?SC%EF%BC%9A%E8%A9%A6%E9%A8%93%20-%20%E5%8D%88%E5%89%8D%E2%85%A1%20-%20%E6%83%85%E5%A0%B1%E5%87%A6%E7%90%86%E5%AE%89%E5%85%A8%E7%A2%BA%E4%BF%9D%E6%94%AF%E6%8F%B4%E5%A3%AB%E3%81%AE%E9%81%8E%E5%8E%BB%E5%95%8F#r3bcd415]]暗号リスト）~
平成２５年３月１日 総務省 経済産業省~
https://www.cryptrec.go.jp/list/cryptrec-ls-0001-2012r4.pdf

**RFC [#b9ce91ba]

***[[RFC4949 Internet Security Glossary, Version 2]] [#s1c90db6]

**Wikipedia [#m138bd58]
-暗号~
https://ja.wikipedia.org/wiki/%E6%9A%97%E5%8F%B7
-暗号理論~
https://ja.wikipedia.org/wiki/%E6%9A%97%E5%8F%B7%E7%90%86%E8%AB%96
-鍵 (暗号)~
https://ja.wikipedia.org/wiki/%E9%8D%B5_(%E6%9A%97%E5%8F%B7)

***ハッシュ関数 [#xcbc775b]
-Category:ハッシュ関数~
https://ja.wikipedia.org/wiki/Category:%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E9%96%A2%E6%95%B0
--ハッシュ関数~
https://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E9%96%A2%E6%95%B0
--暗号学的ハッシュ関数~
https://ja.wikipedia.org/wiki/%E6%9A%97%E5%8F%B7%E5%AD%A6%E7%9A%84%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E9%96%A2%E6%95%B0

***共通鍵暗号 [#qfb90a6d]
-共通鍵暗号~
https://ja.wikipedia.org/wiki/%E5%85%B1%E9%80%9A%E9%8D%B5%E6%9A%97%E5%8F%B7
--ストリーム暗号~
https://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%88%E3%83%AA%E3%83%BC%E3%83%A0%E6%9A%97%E5%8F%B7
--ブロック暗号~
https://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF%E6%9A%97%E5%8F%B7

***公開鍵暗号 [#lf3c7825]
-公開鍵暗号~
https://ja.wikipedia.org/wiki/%E5%85%AC%E9%96%8B%E9%8D%B5%E6%9A%97%E5%8F%B7

--RSA暗号~
https://ja.wikipedia.org/wiki/RSA%E6%9A%97%E5%8F%B7

--Digital Signature Algorithm - Wikipedia~
https://ja.wikipedia.org/wiki/Digital_Signature_Algorithm

--楕円曲線暗号~
https://ja.wikipedia.org/wiki/%E6%A5%95%E5%86%86%E6%9B%B2%E7%B7%9A%E6%9A%97%E5%8F%B7
>具体的な暗号方式の名前ではない。公開鍵暗号が多い。

---楕円曲線DSA~
https://ja.wikipedia.org/wiki/%E6%A5%95%E5%86%86%E6%9B%B2%E7%B7%9ADSA
---ディフィー・ヘルマン鍵共有 - Wikipedia~
https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%A3%E3%83%95%E3%82%A3%E3%83%BC%E3%83%BB%E3%83%98%E3%83%AB%E3%83%9E%E3%83%B3%E9%8D%B5%E5%85%B1%E6%9C%89

***その他 [#w09ced0d]
-初期化ベクトル~
https://ja.wikipedia.org/wiki/%E5%88%9D%E6%9C%9F%E5%8C%96%E3%83%99%E3%82%AF%E3%83%88%E3%83%AB
-暗号利用モード~
https://ja.wikipedia.org/wiki/%E6%9A%97%E5%8F%B7%E5%88%A9%E7%94%A8%E3%83%A2%E3%83%BC%E3%83%89

**Qiita [#ma44ba6a]
-プログラマの暗号化入門~
https://qiita.com/asksaito/items/1793b8d8b3069b0b8d68

-暗号化方式／アルゴリズム／パディング／ブロック化のまとめ~
https://qiita.com/pink/items/f795b0680a2a000e1934

-暗号技術についてのまとめ~
https://qiita.com/g-----ta/items/2554b34e0455fa52f53c

-2つの公開鍵暗号(公開鍵暗号の基礎知識)~
https://qiita.com/angel_p_57/items/897bf94160be8d637585

**[[デジタル証明書>証明書]] [#l634154e]
「[[デジタル証明書>証明書]]」の検証は、「送信側の公開鍵」を拠り所にしていると言えるが、提供される「送信側の公開鍵」の出所が、正規の出所か、検証できない（場合がある）という問題がある。~
このため、この問題を解決するための、「認証局」と呼ばれる、信頼のおける第三者が発行した「[[デジタル証明書>証明書]]」を使用して「送信側の公開鍵」が信頼できるものであるかを検証する機構がある。

**パスワードの保存 [#p0801353]

***ソルト、ストレッチング [#b978c5d9]
ハッシュとソルト、ストレッチングを正しく理解する：本当は怖いパスワードの話 - ＠IT~
http://www.atmarkit.co.jp/ait/articles/1110/06/news154.html

***[[パスワード・クラック>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?SC%EF%BC%9A%E8%84%85%E5%A8%81#dc765db9]] [#j2295dce]

**暗号の年問題 [#k200d2bc]
なお、各種の「暗号化アルゴリズム」の「安全性」の問題については、~
日々、調査・研究が進められていため、NIST やCRYPTREC などから~
公にアナウンスされる情報源を確認のこと。

-2010年問題 - Wikipedia~
https://ja.wikipedia.org/wiki/2010%E5%B9%B4%E5%95%8F%E9%A1%8C

-＠IT > Security＆Trust > もう避けられない？ 暗号の2010年問題~
http://www.atmarkit.co.jp/news/200811/20/rsa.html
-Networkキーワード - 暗号の2010年問題：ITpro~
http://itpro.nikkeibp.co.jp/article/Keyword/20090119/323069/
-ASCII.jp：電子証明書に近づく 「暗号アルゴリズム 2010年問題」~
http://ascii.jp/elem/000/000/550/550217/

**[[.NETの署名・暗号化アルゴリズム]] [#uef3e17d]
.NET Framework、.NET Coreのライブラリで提供される署名・暗号化アルゴリズム

----
Tags: [[:IT国際標準]], [[:セキュリティ]], [[:暗号化]]
トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS