このシナリオでDPAPIを介してAesManagedを使用する理由はありますか？
私のWebアプリケーションが複数のWebサーバーにデプロイされる状況にあり、安全に暗号化されたデータをDBサーバーに保存したいと思います（各WebサーバーにはDBサーバーがペアになっています）。
さて、私が考えていたのは、Encryptクラスを利用するDecryptおよびAesManagedライブラリ関数を実装することでした。これらはサーバーごとに異なるAESキーを使用します（展開時にサーバーごとに新しいAESキーを生成します）。このようにして、各サーバーは異なるキーを使用します。次に、SectionInformation.ProtectSection()を使用してWeb.configで暗号化し、安全なものにします。
しかし、私は ProtectedData クラスに遭遇しました。これはWindows DPAPI機能にフックし、対称的な暗号化と復号化を可能にします。今、私は疑問に思っています。自分の生成したキーでAesManagedを使用することに意味があるのでしょうか、それともProtectedDataを使用してデータを暗号化および復号化するだけですか？それぞれの長所と短所は何ですか？
これはおそらく少し遅れますが、これにつまずく他の人々への勧告としてです。このタイプの問題では、2つの理由から、AesManagedで独自の実装をロールオーバーするよりも常にProtectedDataを使用します。最初に、ProtectedDataで暗号化キーを管理する必要はありません。次に、開発者が自分の暗号を手動で展開する前に理解する必要のあるセキュリティ上の考慮事項がいくつかあり、それでも開発者が間違いを犯して暗号を役に立たないものにする可能性があります。完全に受け入れられ、すでに吟味されたソリューションがすでに利用可能なのに、なぜチャンスを利用して頭痛のリスクを冒すのでしょうか？
ジャスティンが言及したように、独自のキーを使用してからそれらを管理することはできません。これが、OSまたは言語メカニズムを使用してこれを行う理由です。 Javaでは、パスワードで保護されたローカルキーストアがあります。キーを保護するためにOSに依存することの短所は、基盤となるOSが何らかの方法で破損した場合、おそらくそれらのキーを失うことです。 CspParametersでRSACryptoServiceProviderを使用して、独自のキーでストアを作成しないのはなぜですか？
読む： https://msdn.Microsoft.com/en-us/library/tswxhw92.aspx
https://msdn.Microsoft.com/en-us/library/f5cs0acs.aspx
これが役立つと思います。このようにして、OSのキーの選択に制限されることなく、ストアでローカルにキーを保護しながら、独自のキーを安全に保つことができます。
おげんきで ;）