複数の暗号アルゴリズムの組み合わせ

Question

次のことを検討しています。できる限り安全に保護したいデータ ストリームがあります。たとえば、IV を含む AES を適用し、次に IV を含む Blowfish を適用し、最後に IV を含む AES をもう一度適用することに意味はありますか?

暗号化/復号化プロセスは隠蔽されるため (デバッグから保護されることさえある)、どの暗号化方式とどの IV が使用されたかを推測するのは簡単ではありません (ただし、この暗号化チェーンのパワーが依存できないという事実は承知しています)デバッグに対するあらゆる保護は時間が経つと破られる可能性があるため、これはこの事実に基づいています)。

私にはこれ用のコンピューター能力がある（データ量はそれほど大きくない）ので、問題はそれを実装する価値があるかどうかだけです。たとえば、TripleDES は 3 つの IV と暗号化/復号化/暗号化スキームを使用して非常によく似た動作をするため、おそらく完全にナンセンスというわけではありません。もう 1 つの質問は、1 番目と 3 番目のパートに同じ IV を使用した場合、または 3 つのパートすべてに同じ IV を使用した場合に、セキュリティがどの程度低下するかということです。

このテーマに関するヒントを歓迎します

Answer 1

この特定の組み合わせについてはよくわかりませんが、その特定の組み合わせが広範囲に調査されていない限り、このようなものを混ぜるのは一般的に悪い考えです。数学的変換が実際には互いに打ち消し合い、最終的にはハッキングが容易になる可能性があります。AES または Blowfish のいずれかを 1 回パスするだけで十分です。

アップデート：以下私のコメントから…

例として TripleDES を使用する:世界最高の暗号技術者がその組み合わせを作成するのにどれだけの時間と労力を費やしたかを考えてみてください (DoubleDES には脆弱性があることに注意してください)。彼らができる最善のことは、192 ビットのキーにもかかわらず 112 ビットのセキュリティです。

更新 2:AES がそうであるというディオミディスの意見に同意せざるを得ません。 非常に システム内の脆弱なリンクである可能性は低いです。事実上、システムのその他すべての側面は、AES よりも危険にさらされる可能性が高くなります。

更新 3:ストリームで何をしているかによっては、単に使用することもできます TLS (SSLの後継)。お勧めします 実用的な暗号学 詳細については、対処する必要がある多くの懸念事項に非常にうまく対処します。とりわけ、以下について説明します。 ストリーム暗号, これは、AES よりも適切な場合とそうでない場合があります (AES は ブロック暗号 そして、暗号化するデータストリームがあると具体的に述べました）。

Answer 2

ある暗号化アルゴリズムを、最初の暗号化アルゴリズムとは大きく異なる別のアルゴリズムの上に適用しても、失うものは何もないと思います。ただし、間に別のアルゴリズムを実行した場合でも、最初のアルゴリズムに加えて同じアルゴリズムの 2 番目のラウンドを実行することには慎重です。2 つの実行間の相互作用によって脆弱性が生じる可能性があります。

そうは言っても、暗号化の部分で苦労しすぎているように思います。データの漏洩のほとんどは、AES などの業界標準の暗号化アルゴリズムを破ることによって発生するのではなく、システムの他の弱点によって発生します。鍵の管理、暗号化されていないデータの処理、アルゴリズムの実装の弱点 (データや鍵が漏洩する可能性)、およびより広範なシステムの問題 (データのバックアップをどうしているかなど) を検討することにもっと時間を費やすことをお勧めします。

Answer 3

ハッカーは常にチェーン内の最も弱い要素を攻撃します。したがって、強い要素をさらに強くすることはほとんど役に立ちません。AES 暗号化を解読することは、128 ビットのキー長ではすでに不可能です。フグも同様です。さらに長い鍵長を選択すると、さらに困難になりますが、実際には、128 ビットはこれまでに解読されたことはありません (おそらく、今後 10 年か 20 年以内には解読されないでしょう)。この暗号化はおそらく最も弱い要素ではないのに、なぜ暗号化を強化するのでしょうか?もう強いですね。

他に最も弱い要素は何か考えてみませんか?Ⅳは？実際のところ、私は優れた IV を選択したり、それを隠したりすることにあまり時間を無駄にはしません。通常、最も弱いキーは暗号化キーです。例えば。ディスクに保存されているデータを暗号化しているが、このデータをアプリケーションで読み取る必要がある場合、アプリケーションは IV と暗号化キーを知る必要があるため、両方の情報を知る必要があります。 内で バイナリ。実はこれが一番弱い要素なのです。20 の暗号化方式を使用し、それらをデータ上で連鎖させたとしても、20 個すべての IV と暗号化キーがバイナリ内に存在する必要があり、ハッカーがそれらを抽出できる場合、1 つの暗号化方式ではなく 20 の暗号化方式を使用したという事実により、追加の暗号化はゼロになります。安全。

プロセス全体が何なのか（誰がデータを暗号化するのか、誰がデータを復号化するのか、データはどこに保存されるのか、どのように転送されるのか、誰が暗号化キーを知る必要があるのか​​など）がまだ分からないので、非常に難しいです。最も弱い要素が実際に何かを言うのは難しいですが、AES や Blowfish 暗号化自体が最も弱い要素であるとは思えません。

Answer 4

誰からデータを守ろうとしているのでしょうか?あなたの兄弟、競争相手、政府、それとも宇宙人ですか？

これらにはそれぞれ、有意義な予算 (時間/現金) の範囲内で、データが「可能な限り安全である」とみなすことができるさまざまなレベルがあります。

Answer 5

最初はよくわからないかもしれませんが、2 回暗号化する方が 1 回暗号化するより安全です。

直観的には、同じアルゴリズムで 2 回暗号化しても追加の保護は得られないように見えます。攻撃者が最終暗号文から平文まで復号するキーを見つける可能性があるためです。...しかしそうではありません。

例えば。平文から始めます あ そしてキーで暗号化します K1 それを得るために B. 。それから暗号化します B 鍵付き K2 取得するため C.

直感的には、キーが存在する可能性があると考えるのが合理的だと思われますが、 K3, 、暗号化に使用できます あ そして手に入れる C 直接。この場合、総当たり攻撃を行う攻撃者は最終的に次のような攻撃に遭遇することになります。 K3 そして復号化できるようになる C, その結果、追加の暗号化手順によってセキュリティは追加されませんでした。

ただし、そのようなキーが (最新の暗号化方式では) 存在する可能性は非常に低いです。（ここで「ありそうもない」と言うとき、私は普通の人が「ありえない」という言葉を使って表現することを意味します）。

なぜ？
キーは、平文から暗号文へのマッピングを提供する関数と考えてください。
私たちの鍵がすべて揃っているなら クアラルンプール 長さがビットの場合、そのようなマッピングは 2^KL 存在します。
ただし、2つのキーを使用すると、 クアラルンプール それぞれビットなので、(2^KL)^2 のマッピングが得られます。
これらすべてが 1 段階の暗号化と同等であるとは限りません。

2 回暗号化することのもう 1 つの利点は、 2 つの異なるアルゴリズムが使用されている場合, は、いずれかのアルゴリズムで脆弱性が見つかった場合でも、もう一方のアルゴリズムがある程度のセキュリティを提供するということです。

他の人も指摘しているように、キーのブルートフォース攻撃は通常、最後の手段です。攻撃者は多くの場合、他の時点 (例:ソーシャル エンジニアリングを使用してパスフレーズを検出します)。

セキュリティを強化するもう 1 つの方法は、1 つの暗号化アルゴリズムで長いキーを単純に使用することです。

...私の計算を自由に修正してください。

Answer 6

また、アルゴリズムを難読化することに時間を無駄にしないでください。キルヒホフの原則を適用し、AES 自体が、データを「安全」にする必要がある多くの場所で使用されている (そして使用されることが認められている) ことを覚えておいてください。

Answer 7

ダミアン:そうですよね、もっと明確に書いたほうがいいですよ。競合他社のことを言っているのですが、それは商用目的です。つまり、有効な予算が利用可能ですが、なぜそれを行うのかがよくわからないままそれを実装したくありません:)

ハンク:そう、これは私も怖いのです。このアイデアを最も支持する情報源は TripleDES です。その一方で、あるアルゴリズムを使用して一部のデータを暗号化し、その後別のアルゴリズムを適用する場合、暗号化全体の「能力」がスタンドアロンのアルゴリズムを使用する場合よりも低くなるとしたら、非常に奇妙です。しかし、だからといって平等にできないわけではありません...これが私がヒントを求めている理由です、これは私の知識の分野ではありません...

Answer 8

ディオミディス:これは基本的に私の見解ですが、私の同僚は、これが本当にセキュリティを「強化」するものであると私に説得しようとしています。私の提案は、自分が何をしているのかについて考えたり深い知識を持たずにアルゴリズムを次々と使用するのではなく、より強力な暗号化キーを使用することです。

Answer 9

私は、あなたが使用しているアルゴリズムを隠すことに頼るつもりはありません。この種の「隠蔽によるセキュリティ」は長くは機能しません。コードを逆コンパイルすることは、使用している暗号を明らかにする 1 つの方法ですが、通常、人々はこのような秘密を長く保持しません。それが、そもそも秘密鍵/公開鍵暗号を採用している理由です。

Answer 10

@Miro Kropacek - あなたの同僚は Voodoo を通じてセキュリティを追加しようとしています。代わりに、AES のみを使用するなど、欠陥を分析できる単純なものを構築するようにしてください。

デバッグからの保護を通じてセキュリティを強化することを提案したのは彼 (彼女?) だったと思います...

Answer 11

実際に物を作ることはできない 少ない 個別の IV とキーを使用して複数回暗号化すると安全になりますが、セキュリティの向上は予想よりはるかに小さい可能性があります。2DES の例では、中間攻撃は、難易度が 2 倍になるのではなく、突破の難易度が 2 倍になることを意味します。

ただし、一般に、セキュリティを強化する必要がある場合は、単一のよく知られたアルゴリズムを使用し、キーの長さを長くする方がはるかに安全です。暗号システムの構築は専門家に任せてください (私自身が専門家に属するわけではありません)。

Answer 12

はい、有益な場合もありますが、ほとんどの状況ではおそらく過剰です。また、ハンクが述べているように、特定の組み合わせでは実際に暗号化が弱くなる可能性があります。

TrueCrypt は、AES-Twofish-Serpent などの暗号化アルゴリズムの組み合わせを多数提供します。もちろん、それらを使用するとパフォーマンスが低下します。

Answer 13

アルゴリズムを変更しても品質は向上しません (アルゴリズムが壊れることを期待する場合を除く)。それはキー/ブロックの長さと、難読化における何らかの利点に関するものだけです。たとえ最初のキーが漏洩したとしても、結果として得られるデータはランダムなデータと区別できないため、これを数回実行すると興味深いものになります。特定のプラットフォームでより適切に処理されるブロック サイズがあります (例:レジスタサイズ）。

高品質の暗号化アルゴリズムへの攻撃は総当り攻撃によってのみ機能するため、費やすことができるコンピューティング能力に依存します。これは、最終的には、誰かがそれを解読するために必要な可能性のある平均時間を増やすことができることを意味します。

データが 本物 データを攻撃するのではなく、キーホルダーを攻撃する方がよいでしょう...

Answer 14

私は上記の内容に同意します。複数段階の暗号化を行ってもあまりお金はかかりません。「安全な」アルゴリズムを使用している場合、それを破ることは事実上不可能です。一部の標準ストリーミング モードで AES を使用する。見る http://csrc.nist.gov/groups/ST/toolkit/index.html 受け入れられる暗号とモードについて。そのサイトで推奨されているものは、適切に使用すれば十分に安全であるはずです。より安全性を高めたい場合は、AES 256 を使用してください。ただし、いずれにしても 128 で十分です。最大のリスクは、アルゴリズム自体に対する攻撃ではなく、キー管理に対する攻撃、またはサイド チャネル攻撃です (アプリケーションや使用方法によっては、リスクになる場合とならない場合があります)。アプリケーションがキー管理攻撃やサイドチャネル攻撃に対して脆弱な場合、適用する暗号化レベルの数は問題ではありません。ここに私はあなたの努力を集中したいと思います。