5

ランダム アクセス モード (ファイルの任意の部分にアクセス) で機能する必要がある AES に基づくファイル暗号化を構築しています。たとえば、カウンターの AES を使用できますが、2 度使用されない一意のシーケンスが必要であることはよく知られています。この場合、単純化された Fortuna PRNG (特定のファイルに固有のランダムに選択された一意のキーでカウンターを暗号化する) を使用しても問題ありませんか? このアプローチに弱点はありますか?

したがって、暗号化/復号化は次のようになります

オフセットでのブロックの暗号化:

rndsubseq = AESEnc(Offset, FileUniqueKey)
xoredplaintext = plaintext xor rndsubseq
ciphertext = AESEnc(xoredplaintext, PasswordBasedKey)

オフセットでのブロックの復号化:

rndsubseq = AESEnc(Offset, FileUniqueKey)
xoredplaintext = AESDec(ciphertext, PasswordBasedKey)
plaintext = xoredplaintext xor rndsubseq

1 つの観察。フォルトゥナで使われているアイデアは自分で思いついたのですが、後になってそれがすでに発明されていることを発見したのは確かです。しかし、どこでも重要なポイントはセキュリティですが、別の良い点があります。いわば（簡略化された形式で）優れたランダムアクセス疑似乱数ジェネレーターです。したがって、PRNG は非常に優れたシーケンスを生成するだけでなく (Ent と Die Hard でテストしました)、ステップ番号がわかっている場合は任意のサブシーケンスにアクセスできます。では、Fortuna をセキュリティ アプリケーションの「ランダム アクセス」PRNG として使用することは一般的に問題ないのでしょうか?

編集：

言い換えれば、私が提案するのは、Fortuna PRNG を微調整として使用して、ランダム アクセス機能を備えた微調整可能な AES 暗号を形成することです。Liskov、Rivest、Wagner の著作を読みましたが、動作モードの暗号と微調整可能な暗号の主な違いは何かを理解できませんでした。彼らは、このアプローチを暗号自体の内部の高レベルから導入することを提案したと述べましたが、たとえば、私の場合、微調整でプレーンテキストを xor する場合、これは微調整ですか?

4

2 に答える 2

5

「調整可能なブロック暗号」がどのように機能するかを調べて、ディスク暗号化の問題がどのように解決されるかを調べたいと思うかもしれません:ディスク暗号化理論. ディスク全体を暗号化することはあなたの問題に似ています.各セクターの暗号化は個別に行う必要があります（異なるオフセットでデータの個別の暗号化が必要です）が、全体が安全でなければなりません. そのために多くの作業が行われています。ウィキペディアは良い概要を提供しているようです。

編集して追加: あなたの編集について: はい、調整をプレーンテキストと XOR することにより、AES から調整可能なブロック暗号を作成しようとしています。より具体的には、Enc(T,K,M) = AES (K, f(T) xor M) があります。ここで、AES(K,...) はキー K による AES 暗号化を意味し、f(T) は次の関数の一部です。微調整（あなたの場合、それはFortunaだと思います）。あなたが言及した論文を簡単に見ましたが、私が見る限り、この方法はそうではないことを示すことができます安全で調整可能なブロック暗号を生成します。アイデア (Liskov、Rivest、Wagner 論文のセクション 2 の定義に基づく) は次のとおりです。暗号化オラクルまたはランダム順列のいずれかにアクセスでき、どちらとやり取りしているかを知りたい. 微調整 T と平文 M を設定すると、対応する暗号文が返されますが、使用されている鍵はわかりません。構造 AES(K, f(T) xor M) を使用するかどうかを調べる方法を次に示します。任意の 2 つの異なる値 T、T' を選択し、f(T)、f(T') を計算します。任意のメッセージ M を選択し、2 番目のメッセージを M' = M xor f(T) xor f(T') として計算します。次に、暗号化オラクルに、tweak T を使用して M を暗号化し、tweak T' を使用して M' を暗号化するように依頼します。考慮された構造を扱う場合、出力は同じになります。ランダム順列を扱う場合、出力はほぼ確実に (確率 1-2^-128 で) 異なります。これは、AES 暗号化への両方の入力が同じであるため、暗号文も同じになるためです。2 つの出力が同一である確率は 2^-128 であるため、ランダム順列を使用する場合はそうではありません。肝心なのは、入力への xor 調整はおそらく安全な方法ではないということです。

この論文では、安全な構造であることを証明できる例をいくつか挙げています。最も単純なものは Enc(T,K,M) = AES(K, T xor AES(K, M)) のようです。ブロックごとに 2 つの暗号化が必要ですが、この構造のセキュリティが証明されています。より高速なバリアントについても言及していますが、追加のプリミティブ (ほぼ xor ユニバーサル関数ファミリ) が必要です。

于 2009-09-23T11:23:27.213 に答える
1

あなたのアプローチは十分に安全だと思いますが、CTR を超えるメリットはありません。暗号文に真のランダム性を注入しないという、まったく同じ問題があります。オフセットは既知の体系的な入力です。キーで暗号化されていますが、ランダムではありません。

もう 1 つの問題は、FileUniqueKey を安全に保つ方法です。パスワードで暗号化？複数のキーを使用すると、さまざまな問題が発生します。

カウンター モードは、ランダム アクセス ファイルを暗号化するために受け入れられている方法です。あらゆる種類の脆弱性がありますが、すべて十分に研究されているため、リスクは測定可能です.

于 2009-09-22T21:51:28.317 に答える