スタン・ドラプキン。 .NETの高レベル暗号化トラップ

Stan Drapkinは、.NET Frameworkの16年以上の経験を持つセキュリティおよびコンプライアンスの専門家です（2001年の.NET 1.0-beta以降）。 残念ながら、彼自身はロシア語で記事を書いていないので、 彼のレポートの翻訳をDotNext Piterでリリースすることに同意しました。 このレポートは会議で1位になりました！



対称暗号化、非対称、ハイブリッド、高レベル、低レベル、ストリームおよび最新の楕円暗号。 暗号化に関するビデオの56分、およびはるかに高速-テキストの形式で。







カットの下-ビデオ、スライド、翻訳。 読書をお楽しみください！





スライド



私の名前はスタン・ドラプキンです。私は情報セキュリティと規制順守を専門とする会社のテクニカルディレクターです。 さらに、私はいくつかのオープンソースライブラリの作成者でもあり、それらはコミュニティから非常に好評です。 インフェルノを聞いた人は何人ですか？ このライブラリは、.NETでの暗号化への正しいアプローチを示しており、 TinyORMは.NETのmicro-ORMを実装しています。 さらに、今日の記事のトピックに関連する可能性のある本をいくつか書いています。 その1つである2014年版は「Security Driven .NET」であり、2017年のもう1つは「Application Security in .NET、Succinctly」です。



最初に、暗号化啓発の4つの段階と呼ぶものについて説明します。 次に、2つの主要なトピックが続きます。最初のトピックでは対称暗号化について、2番目のトピックでは非対称およびハイブリッドについて説明します。 最初の部分では、高レベル暗号と低レベル暗号を比較し、ストリーミング暗号の例を見てみましょう。 第2部では、RSAで多くの「冒険」を行い、その後、現代の楕円暗号に精通します。



では、暗号化啓発のこれらの段階はどのように見えるのでしょうか？ 最初の段階は、「XORはとてもクールだ、見て、お母さん、どうすればいいか！」です。あなたの多くはきっとこの段階に精通しており、XOR機能の素晴らしさを知っています。 しかし、この段階の大部分が成長し、次の段階、つまり広く知られ、高く評価されているアルゴリズムであるAES（Advanced Encryption Standard）を使用して暗号化と復号化を実行することを学んだことを願っています。 DotNextにアクセスしないほとんどの開発者はこの段階です。 しかし、DotNextに従い、低レベルAPIの危険性に関するレポートに精通しているため、次の段階にいる可能性が高いでしょう。 まあ、全体像を完成させるために、最後の段階にも言及します-問題に対する最善の解決策では、暗号化はまったく必要ないかもしれないという理解です。 この段階は到達するのが最も難しく、人がほとんどいません。 たとえば、ピーターG.ノイマンは次のように語っています。「問題の解決策が暗号化にあると考えている場合、問題の内容を正確に理解することはできません。」



低レベル暗号化が危険であるという事実は、.NETに関する多くのレポートで議論されています。 2015年のVladimir Kochetkovのレポート「Pitfalls of System.Security.Cryptography」を参照できます 。 彼の主なアイデアは、低レベルの暗号化APIを使用する各段階で、知らないうちに多くの決定を下すことであり、その多くについては適切な知識がありません。 主な結論は、理想的には、低レベル暗号化の代わりに高レベル暗号化を使用する必要があるということです。 これは素晴らしい結論ですが、別の問題につながります-高レベルの暗号化がどのように見えるべきかを正確に知っていますか？ それについて少し話しましょう。



非高レベル暗号化APIの属性を定義します。 そもそも、このようなAPIは.NETにネイティブであるという印象を与えるのではなく、低レベルのシェルのように見えます。 さらに、そのようなAPIは簡単に誤って使用されます。 そうではありません。 さらに、ノンス、初期化ベクトルなど、多くの奇妙な低レベルのものを生成することを強制します。 このようなAPIを使用すると、アルゴリズム、パディングモード、キーサイズ、ノンスなどを選択するのではなく、不快な判断を下すことになります。 また、ストリーミング用の正しいAPI（ストリーミングAPI）もありません。後者の外観について説明します。



対照的に、高レベルの暗号化APIはどのように見えるべきですか？ そもそも、コードの読み取りと書き込みの両方について、直感的かつ簡潔でなければなりません。 さらに、このようなAPIは簡単に習得して使用でき、間違った方法で適用することは非常に難しいはずです。 また、強力である必要があります。つまり、少しの労力と少量のコードで目標を達成できる必要があります。 最後に、このようなAPIには一般に制限、警告、特殊なケースの長いリストを含めるべきではありません-それを操作する際に覚えておく必要のある最小限のものがあるはずです-言い換えれば、低レベルの干渉（低摩擦）によって特徴付けられるべきです予約なしで動作します。



.NETの高レベル暗号化APIの要件を理解したので、今どのようにそれを見つけるのでしょうか？ あなたはただグーグルを試すことができますが、それはあまりにも原始的です-私たちはプロの開発者であり、これは私たちの方法ではありません。 そのため、この問題を調査し、さまざまな選択肢をテストしています。 ただし、このためには、まず、認証された暗号化とは何かという正しい考えを自分自身で補う必要があり、そのためには基本的な概念を理解する必要があります。 それらは次のとおりです。プレーンテキストP（プレーンテキスト）。これは、秘密キーK（キー）を使用して同じ長さの暗号テキストC（暗号テキスト）に変換します。 ご覧のとおり、これまでのところ、非常に単純なスキームを使用しています。 さらに、認証タグTとnonce Nもあります。重要なパラメーターはN̅です。つまり、1つのキーでnonceを再利用します。 おそらくご存知のように、それはテキストの機密性の侵害につながりますが、これは明らかに望ましくありません。 もう1つの重要な概念はAD（関連データ）、つまり関連データです。 これは認証されるオプションのデータですが、暗号化と復号化には関与しません。







基本概念を理解したので、.NETの暗号化ライブラリのさまざまなオプションを見てみましょう。 Libsodium.NETを分析することから始めましょう。 彼女を何人知っていますか？ 私が見るように、いくつかはおなじみです。

nonce = SecretAeadAes.GenerateNonce(); c = SecretAeadAes.Encrypt(p, nonce, key, ad); d = SecretAeadAes.Decrypt(c, nonce, key, ad);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

暗号化がLibsodium.NETで実行されるC＃コードは次のとおりです。 一見すると、それは非常にシンプルで簡潔です。1行目ではノンスが生成され、2行目では暗号化自体が行われ、3行目ではテキストが復号化されます。 それは思われた-どのような困難がある可能性がありますか？ そもそも、Libsodium.NETは対称暗号化の1つではなく3つの異なる方法を提供します：



回

 nonce = SecretAeadAes.GenerateNonce(); c = SecretAeadAes.Encrypt(p, nonce, key, ad); d = SecretAeadAes.Decrypt(c, nonce, key, ad);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

二

 nonce = SecretAead.GenerateNonce(); c = SecretAead.Encrypt(p, nonce, key, ad); d = SecretAead.Decrypt(c, nonce, key. ad);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

三

 nonce = SecretBox.GenerateNonce(); c = SecretBox.Create(p, nonce, key); d = SecretBox.Open(c, nonce, key);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

明らかに、問題が発生します-あなたの特定の状況でどちらが良いですか？ それに答えるには、これらのメソッドの内部に入る必要があります。



最初のメソッドSecretAeadAes



は、96ビットのノンスでAES-GCMを使用します。 彼がかなり長い制限リストを持っていることが重要です。 たとえば、それを使用する場合、1つのキーで550ギガバイトを超えて暗号化するべきではありません。また、1つのメッセージで最大2 ^32のメッセージを含む64ギガバイトを超えてはなりません。 さらに、ライブラリはこれらの制限に近づいていることを警告していません。あなたはそれらを自分で追跡する必要があり、開発者としてあなたに追加の負担をかけます。



2番目の方法であるSecretAead



は、異なる暗号スイートChaCha20/Poly1305



し、大幅に小さい64ビットのナンスを使用します。 このような小さなナンスは衝突を極めて可能性が高いため、この理由だけで、この方法は使用しないでください-非常にまれなケースを除き、トピックに精通している場合を除きます。



最後に、3番目のメソッドSecretBox



。 このAPIの引数には関連するデータがないことに注意してください。 ADで認証された暗号化が必要な場合、この方法は適していません。 ここで使用される暗号化アルゴリズムはxSalsa20/Poly1305



と呼ばれ、ノンスは十分に大きいxSalsa20/Poly1305



ビットです。 ただし、ADの欠如は重大な制限です。



Libsodium.NETを使用すると 、いくつかの疑問が生じます。 たとえば、上記の例のコードの最初の行で生成されたノンスを使用して、正確に何をすべきでしょうか？ ライブラリはこれについて何も教えてくれません。私たちは自分でそれを理解しなければなりません。 ほとんどの場合、このノンスを暗号文の最初または最後に手動で追加します。 さらに、最初の2つの方法のADの長さには制限がないという印象を受けるかもしれません。 しかし、実際には、ライブラリは16バイト以下のADをサポートしています。結局のところ、16バイトで十分です。 続けましょう。 復号化エラーはどうなりますか？ このライブラリでは、これらの場合に例外をスローすることが決定されました。 復号化中の環境でデータの整合性が侵害される可能性がある場合、多くの例外を処理する必要があります。 キーサイズが正確に32バイトではない場合はどうなりますか？ ライブラリはこれについては何も教えてくれません。これらはあなたが興味を持たない問題です。 別の重要なトピックは、集中的なシナリオでガベージコレクターの負荷を軽減するためのバイト配列の再利用です。 たとえば、コードでは、nonceジェネレーターが返す配列を確認しました。 毎回新しいバッファを作成するのではなく、既存のバッファを再利用したいと思います。 これはこのライブラリでは不可能であり、バイトの配列は毎回再生成されます。



すでに見たスキームを使用して、さまざまなLibsodium.NETアルゴリズムの比較を試みます。







最初のアルゴリズムであるAES-GCMは、96ビット長のノンスを使用します（図の黄色の列）。 128ビット未満であるため、多少の不快感が生じますが、それほど重要ではありません。 次の列は青です。これは認証タグが占める場所で、AES-GCMでは16バイトまたは128ビットです。 括弧内の2番目の青い数字は、このタグに含まれるエントロピーまたはランダム性の量を意味します-128ビット未満。 どれだけ少ない-このアルゴリズムでは、暗号化されるデータの量に依存します。 暗号化するほど、タグは弱くなります。 これだけでも、このアルゴリズムに関する疑問が生じるはずであり、白い列を見ると増加します。 ノンスの繰り返し（衝突）は、同じキーで作成されたすべての暗号文の偽造につながると言われています。 たとえば、2つの共通キーによって作成された100個の暗号テキストのうち、ノンスの衝突がある場合、このノンスは認証キーの内部リークを引き起こし、攻撃者がこのキーによって作成された他の暗号テキストを偽造できるようにします。 これは非常に重要な制限です。



2番目のLibsodium.NETメソッドに進みましょう。 先ほど言ったように、ここでは一回だけ、使用されるスペースが少なすぎて64ビットしかありません。 タグは128ビットを占有しますが、エントロピーは106ビット以下、つまり、ほとんどの場合達成しようとする128ビットのセキュリティレベルよりも大幅に低いです。 偽造に関しては、ここでの状況はAES-GCMの場合よりも若干良くなっています。 ノンスの衝突は暗号文の改ざんにつながりますが、衝突が発生したブロックのみです。 前の例では、100ではなく2つの暗号文を偽造していました。



最後に、xSalsa / Polyアルゴリズムの場合、192ビットの非常に大きなノンスがあり、衝突が非常に起こりにくくなります。 認証方法は前の方法と同じであるため、タグは再び128ビットを使用し、106ビット以下のエントロピーを持ちます。



これらのすべての数値を、 Infernoライブラリの対応するインジケーターと比較します。 その中で、ノンスは、320ビットの巨大なスペースを占有し、衝突をほとんど不可能にします。 タグについては、すべてがシンプルです。正確に128ビットを占有し、正確に128ビットのエントロピーを持っています。 これは、信頼性が高く安全なアプローチの例です。



Libsodium.NETの詳細を知る前に、その目的を理解する必要があります-残念ながら、このライブラリを使用するすべての人が認識しているわけではありません。 これを行うには、 Libsodium.NETがlibsodiumのC＃ラッパーであると述べているドキュメントを参照してください。 これは別のオープンソースプロジェクトであり、そのドキュメントには、互換性のあるAPIを備えたNaClのフォークであることが記載されています。 さて、別のオープンソースプロジェクトであるNaClのドキュメントを参照してください。 その中で、目標として、 NaClは高度な暗号化ツールを作成するために必要なすべての操作を提供すると仮定されています。 犬が埋葬されるのはここです。NaClとそのすべてのシェルのタスクは、低レベルの要素を提供することです。そこから、誰かがすでに高レベルの暗号化APIを組み立てることができます。 高レベルのライブラリとしてのこれらのシェル自体は考案されていません。 したがって、モラル：高レベルの暗号化APIが必要な場合、高レベルのライブラリを見つけ、低レベルのラッパーを使用せず、高レベルのライブラリで作業しているふりをする必要があります。



Infernoでの暗号化の仕組みを見てみましょう。







Libsodiumの場合のように 、各暗号化と復号化に必要なコードは1行のみです。 引数は、キー、テキスト、およびオプションの関連データです。 ノンスがなく、決定を行う必要がないことに注意する必要があります。復号化エラーの場合、例外をスローせずにnullが返されるだけです。 例外を作成すると、ガベージコレクタの負荷が大幅に増加するため、例外が存在しないことは、大きなデータストリームを処理するスクリプトにとって非常に重要です。 このアプローチが最適であると納得できたことを願っています。



興味深いことに、文字列を暗号化してみましょう。 これは、誰でも実装できる最も単純なシナリオでなければなりません。 「LEFT」と「RIGHT」の2つの異なる文字列値しか使用できないとします。







写真では、 Infernoを使用したこれらの行の暗号化を確認できます（ただし、この例では、使用するライブラリは関係ありません）。 1つのキーで2行を暗号化し、2つの暗号文c1



とc2



を取得します。 このコードのすべてが正しいですか？ 彼は生産の準備ができていますか？ 誰かが問題は短期間で可能だと言うかもしれませんが、それは主要な問題からはほど遠いので、キーは同じように使用され、十分な長さがあると仮定します。 c1



、従来の暗号化アプローチでは、この例のc1



はc2



よりも短くなります。 これは長さリークと呼ばれます。多くの場合、 c2



はc1



より1バイト長くなります。 これにより、攻撃者は、この暗号化テキスト「LEFT」または「RIGHT」で表される文字列を理解できます。 この問題を解決する最も簡単な方法は、両方の行の長さを同じにすることです。たとえば、LEFT行の最後に文字を追加します。



一見したところ、長さの漏れは、実際のアプリケーションでは発生し得ない、やや大げさな問題として認識されています。 しかし、2018年1月に、「Tinderに暗号化がないため、画面をスワイプしたときに部外者が追跡できる」という見出しの下で、イスラエルの会社Checkmarxが実施した調査による記事がWired誌に掲載されました。 コンテンツについて簡単に説明しますが、最初にTinder機能の大まかな説明をします。 Tinderは、写真付きのストリームを受信し、写真が好きかどうかに応じて、画面を右または左にスワイプするアプリケーションです。 研究者は、コマンド自体はTLSとHTTPSを使用して正しく暗号化されていますが、右側のコマンドのデータは左側のデータとは異なるバイト数を必要とすることを発見しました。 これはもちろん脆弱性ですが、それ自体はそれほど重要ではありません。 Tinderにとってより重要なのは、暗号化なしで、通常のHTTP経由で写真付きのストリームを送信したという事実です。 そのため、攻撃者は写真に対するユーザーの反応だけでなく、写真自体にもアクセスする可能性があります。 したがって、ご覧のとおり、長さのリークは非常に現実的な問題です。



次に、ファイルを暗号化してみましょう。 すぐに、 Libsodium.NETファイル暗号化、またはもっと広く言えば、ストリーム暗号化はデフォルトでは実装されておらず、手動で行わなければならないことを言わなければなりません。 Infernoの方がはるかに優れています。







上記の例は、MSDNからほとんど変更を加えずに撮影した例です。 これは非常に簡単です。ここでは、ソースファイル用のストリームと宛先ファイル用のストリームのほか、最初のストリームを2番目に変換する暗号化ストリームがあります。 このコードでは、 Infernoは 1行でのみ使用されます-変換が行われる行で。 ですから、私たちの前にあるのは、ストリームを暗号化するためのシンプルかつ同時に完全に機能し、テストされたソリューションです。



同じキーで暗号化する場合、メッセージ数に制限があることに注意してください。 それらはInfernoに存在し、このライブラリでは画面上に明確に書かれています。 しかし、同時に、それらはインフェルノでは非常に大きいため、実際には到達することはありません。 Libsodium.NETでは、制限はアルゴリズムごとに異なりますが、すべての場合において、それを超えるには十分に低いです。 したがって、個々のシナリオでそれらが達成されるかどうかを確認する必要があります。



また、関連するデータの認証についても説明する必要があります。これは、あまり取り上げられないトピックであるためです。 ADは「弱い」可能性があります。これは、認証されていることを意味しますが、暗号化および復号化プロセス自体には関与していません。 対照的に、「強力な」ADはこのプロセス自体を変更します。 私が知っているほとんどのADライブラリは脆弱ですが、 Infernoは暗号化/復号化プロセス自体でADが使用される2番目のアプローチを使用しています...



また、高レベルの暗号化のためにどのレベルのセキュリティが努力すべきかについても検討する必要があります。 要するに、私の答えは次のとおりです。128ビット認証タグを使用した256ビット暗号化。 キーがそんなに大きいのはなぜですか？ これには多くの理由がありますが、それぞれが重要ですが、暗号キーを生成する際にバイアスから身を守る必要があるということを覚えておいてください。 バイアスの意味を説明しましょう。 バイアスのないランダムビットジェネレーターの場合、各ビットについて、値0または1を受け入れる確率は等しくなります。 しかし、ジェネレータで、ビットが50％ではなく56％の確率で値1を取ると仮定します。 一見したところ、このバイアスは小さいですが、実際には25％という大きなものです。 ここで、ジェネレーターで特定のビット数を生成するときに得られるエントロピーの量を計算してみましょう。







写真には、この計算が行われる式が表示されます。 重要なのは、変数が2つしかないことです。すでに説明したバイアス（バイアス）と、ジェネレーターによって作成されるビット数です。 バイアスは25％であると仮定します-これは非常に極端なケースであり、実際には、このような歪んだ乱数ジェネレーターを備えたシステムでは動作しない可能性があります。 25％のバイアスと128ビットのキーを使用すると、53ビットのエントロピーしか得られない可能性があります。 第一に、それは通常乱数発生器から期待される128ビットよりも大幅に小さく、第二に、現代の技術では、そのようなキーは単純にブルートフォースになります。 ただし、128ビットキーの代わりに256ビットを使用すると、106ビットのエントロピーが得られます。 予想される256よりも少ないものの、これは既に非常に優れています。最新の技術では、このようなキーを解読することはほとんど不可能です。



レポートの最初の部分の最後に、中間結果を要約します。 誰もが適切に作成された暗号化APIを使用することをお勧めします。 自分に合ったものを見つけるか、Microsoftに請願書を送り、あなたに手紙を書いてください。 さらに、APIを選択するときは、スレッドを操作するためのサポートの可用性に注意する必要があります。 すでに説明した理由により、最小キー長は256ビットである必要があります。 最後に、高レベル暗号化は、他のものと同様に理想的ではないことを心に留めておく必要があります。 リークが発生する可能性があり、ほとんどのシナリオでその機能を念頭に置いておく必要があります。



非対称暗号、またはハイブリッド暗号について説明しましょう。 私はトリックの質問を投げかけます：.NETでRSAを使用できますか？ 多くの人がそうするように、急いで答えてはいけません-最初にこの分野であなたの知識をテストしましょう。 次のスライドは、このトピックにすでに精通している人向けに特別に設計されています。 しかし、最初にウィキペディアを見て、誰かがこのアルゴリズムを長い間忘れたり、使用しなかった場合に備えて、RSAが何であるかを覚えておいてください。







乱数ジェネレーターを使用して、1つのプライベートと1つのパブリックを含むキーペアを作成するアリスがいるとします。 次に、アリス宛のメッセージを暗号化するボブがいます。「こんにちは、アリス！」彼女の公開鍵を使用して、彼は暗号文を生成し、それを彼女に送信します。 彼女は自分の鍵の秘密部分を使用してこの暗号文を解読します。



このシナリオを実際に再現してみましょう。







上記でわかるように、RSAのインスタンスを作成し、テキストを暗号化します。 .NETがパディングモードの選択を強制することに直ちに注意を払ってください。 それらは5つありますが、すべて名前はわかりません。 これらすべてを順番に試してみると、最後の3つは単に例外をスローし、機能しないことがわかります。 残りの2つのうちの1つ、 OaepSHA1



ます。 ここで、キーのサイズは1キロビットで、RSAには小さすぎますが、実際にはハッキングされたキーです。 したがって、キーサイズを手動で設定する必要があります。 ドキュメントから、キーサイズを受信または設定する特別なプロパティ.KeySize



があることが.KeySize



ます。







一見したところ、これはまさに私たちが必要とするものなので、 rsa.KeySize = 3072



書きます。 しかし、あいまいな疑いに導かれた後、キーサイズが現在何に等しいかを確認すると、1キロビットかかることがわかります。 重要ではありませんWriteLine(rsa.KeySize)



メソッドまたはrsa.ExportParameters(false).Modulus.Length * 8



を使用してこのパラメーターをチェックしますrsa.ExportParameters(false).Modulus.Length * 8



後者の場合、RSAキーのパブリックコンポーネントがエクスポートされます。 このキーのモジュラスは配列で、これに8を掛けてビット単位のサイズを取得します-これも1キロビットになります。 ご覧のとおり、このアルゴリズムはまだ本番環境に送信するには早すぎます。



このAPIが機能しない理由を理解するのに時間を無駄にせず、代わりに、Microsoftが.NET 4.6で提供する別のRSA実装、つまり完全に新しいものを試してください。 RSACngと呼ばれ、 Cngは次世代暗号化の略です。 次世代のツールを使いたくない人はいますか？ きっとここですべての問題に対する魔法の解決策を見つけるでしょう。







RSACngのインスタンスを要求し、再びキーサイズを3キロビットに設定し、再びWriteLine(rsa.KeySize)



キーサイズを確認します。キーサイズがまだ1キロビットに等しいことを確認します。 さらに、キーを生成したオブジェクトのタイプをリクエストした場合-思い出したように、RSACngのインスタンスをリクエストしました-RSACryptoServiceProviderであることがわかります。 私は自分の絶望感をここで共有したいだけで、「なぜマイクロソフトなのか！」と叫ぶだけです。



長い苦痛と苦痛の後、実際には工場ではなくデザイナーを使用する必要があることがわかります。







ここで、デフォルトのキーサイズの値は2048ビットですが、これはすでにはるかに優れています。 さらに良いこと-ここで、ようやくキーサイズを3キロビットに設定することができます。 彼らが言うように、成果はアンロックされました。



これまでのすべての努力はRSAの作成にのみ軽減され、暗号化はまだ開始されていません。最初に答える必要がある質問がまだあります。まず第一に、デフォルトのキーサイズにどの程度まで依存できますか？RSAファクトリの実装はでオーバーライドされる可能性があるmachine.config



ため、知らないうちに変更される場合があります（たとえば、システム管理者が変更する場合があります）。これは、デフォルトのキーサイズも変更できることを意味します。したがって、デフォルトで提供される値を信頼するべきではありません。キーサイズは常に独立して設定する必要があります。次に、デフォルトのRSAキーのサイズはどれくらいですか？.NETには2つのRSA実装があり、1つはベースRSACryptoServiceProvider



、もう1つはベースRSACng



. 1 , . Bitcoin (BCN). , Bitcoin , . hashrate, 2 ⁶⁴ . 2 ⁹⁰ . , — , . , , , , 2 ⁷⁰ ( BCN) , 1- RSA, 2 ⁹⁰ ( BCN) — 2- . — , . , 3 , — 4.



.NET , .







RSA, RSACryptoServiceProvider



, RSACng



, 4 . , . , API — , , . , , , , . RSA , . , API .



, RSA , ; - .







, ( data



), , . . ; ? — Microsoft, , . , . . , . , , . . .



, , SHA-1? SHA-1, , - , - (compliance department) , . OaepSHA1



OaepSHA256



, .







. , , , , .



, , . int GetMaxDataSizeForEnc(RSAEncryptionPadding pad)



, , . , , . , , RSA, . , Microsoft.



, RSA , . , , , API RSA .NET . , , . , 128- 4- . , -, -. . 256- , — 15360 . RSA . . RSA , , , . ? TLS RSA, . , , , , , . , RSA.



, RSA? . ECDSA (Digital Signature Algorithm, « »), RSA . EC — , Elliptic-Curve («»). securitydriven.net/inferno/#DSA Signatures ECDSA, , , .NET. — ECIES (Integrated Encryption Scheme, « »). RSA, , , . securitydriven.net/inferno/#ECIES example. , — ECDH (Diffie-Hellman key exchange, « -»). . ( forward secrecy ). securitydriven.net/inferno/#DHM Key Exchange .



. API, , . RSA. , , , , . RSA. , (ECDSA, ECDH, ECIES). , , , , . StackOverflow, : « . ».



, , , . SecurityDriven.Inferno . « » - (Jean-Philippe Aumasson, Serious Cryptography). . , Application Security in .NET, Succinctly, . .NET. , Slideshare , , .



, . -, , . . .NET — CSRF (Cross-Site Request Forgery, « »), , . — , . , GET. CSRF, HTML «hidden». , cookie-, . POST, . , -, , , -, . . , ASP.NET ASP.NET Core. , CSRF .



, CSRF . , — , , , . . , (injection) , . — , AJAX, — . , , , .







, — . , , . , .

広告の分。 DotNext. DotNext 2018 Moscow — 22-23 2018 - « ».



. , , . ! .