.NET の CryptoStream に代わるシーク可能な方法を知っている人はいますか?
代替が「読み取り」モードでのみシークをサポートする場合、または AES256 などに制限されている場合は問題ありません。
.NET の CryptoStream に代わるシーク可能な方法を知っている人はいますか?
代替が「読み取り」モードでのみシークをサポートする場合、または AES256 などに制限されている場合は問題ありません。
ブロック単位の暗号化は完全に安全です。問題があるのはECBだけです。実装は、おそらくOFBまたはCTRモードのいずれかを使用して記述できます。しかし、私はそれを見つけることができませんでした。弾丸を噛んで書くかもしれません...
アップデート:
だから私はこれの実装を書きました。さまざまな理由から、今はここに投稿しません(いつか投稿しようとします)が、これを実行しようとしている人へのヒントをいくつか示します。
CBCモードでRijndaelManagedトランスフォームを使用します。ブロックごとに暗号ストリームを計算します。これを行うには、変換でキーと空の(すべてゼロの)ivを初期化します。実際のivは、ブロックごとに計算されます。
ナンスプラスivプラスカウンターを連結または計算することにより、現在のブロックへの入力を計算するメソッドが必要になります。ここでは、nonce&ivの事前計算など、いくつかの最適化を行うことができます(このメソッドは何度も呼び出されるため、おそらく価値があります)。
例:byte [] GetCurrentCounterBlock(byte [] nonce、byte [] iv、UInt32 counter)
(注:ここでの「iv」とは、NISTがIVと呼んでいるものを意味します。これは、ブロック全体の中央部分であり、他の人がまとめてIVと呼んでいます)
データを暗号化するループ内でこのメソッドを使用します。これを最初に呼び出し、次にブロック境界で呼び出して、現在の暗号ストリームを更新します。このメソッドは、変換のTransformBlockメソッドへの入力を提供します。変換からの出力を取得し、結果を現在のデータブロックに対してXORします。各ブロックが暗号化された後、transform.Reset()を使用してください!それ以外の場合、CBCは変換からの出力を次への入力として使用しようとします。.NETでこれを行うためのより賢い方法があるかもしれませんが、私はそれを理解することができません。BouncyCastleがOFBを「ネイティブに」サポートしていることは知っているので、より良いオプションかもしれませんが、これは、外部の担当者なしで再利用性の高い暗号ストリームを取得するための優れた高速な方法です。
とにかく、重要なのは、このメソッド全体(私はそれをAesCtr256.Processと呼んでいますが、もっと一般的である可能性があります)が暗号ストリーム内の任意の範囲のデータで機能することです。このメソッドは、カスタムStreamクラス内で簡単に使用できます。これにより、読み取りと書き込みの両方でストリーム内の任意の場所をシークでき、バイトアラインされたデータを処理できるようになります(実際に実際のデータ長を報告する暗号ストリームを使用できるようになったので、本当に便利です)。
別の言い方をすれば、ストリームの任意の部分の暗号ストリームを計算してから、暗号またはプレーンテキストに対して単純にxorして暗号化/復号化します。
最後に2つ:1。)ストリームの存続期間中、変換を再利用することを強くお勧めします。これらを作成するにはコストがかかります。2.)この書き込みユニットテストをNISTベクトルまたは同様のものに対して実装する場合。これが正しいと思い込まないでください。出力がランダムに見えるからといって、正しく暗号化されているとは限りません:)。
誰かがより良いアプローチについて、または私が本当に重要なコードを完全に台無しにした方法について何か考えがある場合は、投稿してください、ありがとう!
このような実装はあまり役に立たないと思います.ECBSeek
スタイルの連鎖、つまりブロックを個別に暗号化することで(比較的、アルゴリズムに応じて)一定の時間でしか操作を実行できないため、これは非常にお勧めできません-このウィキペディアの画像を参照してください不安の驚くべき例の記事。
私には、MemoryStream
または同様のラッピング手法にコピーしたり、コピーしたりすることで、より良い結果が得られるように思えます。