ccrypt 'AES 256'ファイルの暗号化は根本的に欠陥がありますか
Unix/linuxユーティリティのccryptは、古いunix cryptのより安全な代替品であると主張しています。しかし、それは根本的な欠陥を持っているように私には思えます。
Ccryptを使用してファイルを暗号化する場合、AESで使用するランダムな256ビットキーを作成するために指定したパスワードが使用されます。パスワードを指定したファイルを再度復号化するために、ccryptはパスワードを使用してAESキーを取得し、ファイルを復号化します。
OK、ファイルは256ビットAESを使用して安全に暗号化されますが、そのセキュリティは完全にキーが安全であることに依存しています-そしてキーis n't安全です。
解読するとき、ccryptは実際に、キーの解読に使用されたパスワードが正しいかどうかを通知し、間違ったキーを入力しても解読を試みません。したがって、あなたが正しく推測したときにキーをブルートフォースで通知することは簡単です。
この問題は、このアプローチを使用するすべてのファイル暗号化に適用されます。重要なのはキーのセキュリティであり、実際のデータのエンコードに使用されるアルゴリズムはほとんど関係ありません。
転送中のメッセージなどを保護するためにメッセージなどを暗号化する場合、キーベースの暗号化は理にかなっていますが、「固定」ファイルの暗号化は異なります。キーが個別に保持されるGPGファイルの暗号化でさえあまり役に立ちませんが、GPGが使用され、キーが「よく知られている」場所に保持されていることは通常明白です。ここでも、重要なセキュリティが重要であり、ファイルの暗号化は無関係です。
OK、1つcouldキーをUSBスティックなどに置くことで完全に分離しますが、ほとんどのファイル暗号化ではこれは少しOTTであり、とにかくスティックを失うとデータを失うことになります。ファイルは通常、長期間保持する必要があるものであり、キーはファイルと一緒にバックアップする必要があります。
単純なファイル暗号化の場合は、古いDESベースの暗号化の方が良いと思います。それを強制するのははるかより難しいと思います。
私はこれを完全に間違っていますか？ :-)
パスワードベースの暗号化は、本質的に辞書攻撃に対して脆弱です。実際、暗号化されたファイルがある場合は、常に、指定されたパスワードを使用してそのファイル（またはその一部）を復号化し、その結果が意味をなすかどうかを確認できます。したがって、暗号化されたファイルを手に入れることができる攻撃者（そうしないと暗号化しても意味がないため、これが可能であると想定します）は、一致が見つかるまで自分のマシンで「パスワードを試行」できます。攻撃者は「結果が理にかなっている」部分について100％信頼できるテストを必要としないことに注意する必要があります。攻撃者のテストが99.9999％の間違ったパスワードを拒否するのに十分である場合、攻撃者はパスワードのリストを減らして再確認します。 100万倍。
ccrypt などのツールが間違ったパスワードを拒否するためのテストを提供することは、この事実を変更しません。確かに、攻撃者はテストを使用することもできますが、追加の利点はあまりありません。実際のデータには多くの構造があり（ほとんどのファイル形式には非常に認識可能なヘッダーがある）、攻撃者がパスワードを解読することに興味がある場合、データは貴重である必要があるため、攻撃者はそのテストがなくても快適に作業できます。 -生活"。
パスワードベースの暗号化を強化する方法は2つあります。これらは累積的であり、両方を使用する必要があります。最初の方法は、強力なパスワードを使用することです。つまり、多くのランダム性を含むパスワードを使用します（通常、その件に関する議論については この質問 を参照してください）。 2番目の方法は、適切に構成された適切な password hashing function ;を使用してパスワードを暗号化キーに変換することです。 「適切な構成」とは、ソルトを使用して並行攻撃を防止し（異なるパスワードを持つ複数の暗号化ファイルがあり、攻撃者がそれらの1つまたは複数を解読したい場合）、パスワードハッシュ関数が作成されることを意味します。辞書攻撃をより困難にするために、多くの反復を通じて意図的に高価になっています。
後者の点では、ccryptに欠陥があるように見えます。 [〜＃〜] faq [〜＃〜] が次のように記述しているパスワードをハッシュします。
Ccryptは、AES（つまり、Rijndaelブロック暗号）に基づくハッシュアルゴリズムを使用します。これは、SHA1などの標準的なハッシュアルゴリズムの1つではありません。したがって、アプリケーションについては、大丈夫です。セキュリティの観点からは、衝突のない限り、どのハッシュアルゴリズムを使用してもかまいません。
これはうまく行きません。最初に、それは作者自身のWordによるカスタムの自家製関数であり、これは決して良い兆候ではありません。さらに、作者は「衝突のない」必要がある機能について語っています。これは、パスワードベースのキー導出にはまったく関係がないため、そのような要件の把握が比較的不十分であることを示しています。これは、特に自家製の関数と組み合わせた場合も、良い兆候ではありません。
ソースコードを見ると（これはオープンソースのいいところです：作成者がドキュメントに適合していないことを自分で確認できます）、カスタムハッシュは次のように機能するように見えます。
- [〜＃〜] k [〜＃〜]と[〜＃〜] h [〜＃〜]を両方に設定値0x00の32バイトのシーケンスである。
- 各パスワード文字c（1バイト、ここではUTF-8などのASCII互換エンコーディングを使用しています）には、次のようにします。
- [〜＃〜] k [〜＃〜]のすべてのバイトをcとXORします。
- [〜＃〜] h [〜＃〜]を[〜＃〜] h [〜＃〜]キー[〜＃〜] k [〜＃〜]およびブロックサイズ256ビットでRijndaelを使用します。
- [〜＃〜] h [〜＃〜]の最終値は「ハッシュされたパスワード」です。
これには、次のコメントが必要です。
FAQは「AES」と言いますが、AESではありません。 [〜＃〜] aes [〜＃〜] は、サブセットである3つの関数のファミリですRijndaelと呼ばれる関数のファミリーの1つです。AESは常に128ビットブロックを使用します。ここでは、Rijndaelは256ビットブロックで使用されるため、AESstricto sensuではありません。
ハッシュ関数としては吸います。プロセスは基本的に、1つのブロックを繰り返し暗号化することに要約されます。可能な暗号化キーの1つを毎回使用します（各暗号化キーの32バイトは常に互いに同一です）。これは対称暗号化であるため、対称復号も機能し、ミートインザミドル攻撃が可能になります。基本的に、出力サイズは256ビットですが、プリイメージ耐性はせいぜい2です。1282ではなく256;これはパスワードハッシュの緊急の問題ではありませんが、カスタムスキームの根本的な欠陥を示しています。
password hashing関数として、それは悪臭を放ちます。無塩であるだけでなく、非常に高速です。基本的なPCを使用する攻撃者は AES-NI 命令を使用して、数十クロックサイクルでRijndael暗号化を計算します（AES-NI命令は特にAESをサポートするためのものですが、 256ビットブロックを効率的にサポートするために引き続き使用できます この論文 ）のセクション2.1を参照してください。さらに、パスワードのバイトは1つずつ処理されるため、ハッシュ化されたパスワード「foo」から、「fooA」、「fooB」、「fooC」のハッシュのように、連続するパスワード試行間で多くの計算コストを共有できます。 ..それぞれに対して単一のRijndael-256呼び出しで計算できます。
安価な市販のPCは、1秒あたり少なくとも100数百万の潜在的なパスワードをハッシュできると推定できます。人間が選んだパスワードはほとんどなく、せいぜい数分でそのような攻撃に耐えることができます。パスワードのハッシュに関しては、これはひどいです。
要約：ccryptは辞書攻撃に対して不当に弱いですが、パスワードの正しさのテストがあるためではありません。そのパスワードハッシュ手順は、辞書攻撃を非常に効率的にする欠陥を蓄積する自家製の構造であるため、弱いです。適切に構成されたパスワードハッシュ関数（例： bcrypt ）を使用すると、文字通り100万倍強力になります（PCが100の代わりに毎秒100のパスワードのみをハッシュできるように反復回数が調整されます）数百万; 1/100秒は人間の観点から見れば大きなレイテンシではないため、それでも使用率は高くなります）。
Ccryptはソルトを使用せず、真のAESを使用せず、標準のKDFを使用しないことを説明する元の回答： https://www.mathstat.dal.ca/~selinger/downloads/ccrypt-answer。 txt
私はccryptの作者です。このスレッドに返信が遅くなって申し訳ありませんが、最近気づかされただけです。いつものように、SourceForgeのccryptフォーラムで、ccryptに関する質問を私に送信することもできます（より迅速な応答が得られる可能性があります）。
元の質問に対処するには、ccryptは他のすべてのパスワードベースの暗号化プログラムと同様に、辞書攻撃を含むブルートフォース攻撃の対象となることを明確に述べさせてください。 Thomas Porninが適切に述べているように、「パスワードベースの暗号化は本質的に辞書攻撃に対して脆弱です」。攻撃者が考えられるすべてのパスワードを試すことを妨げるものはありません。これは欠陥ではなく、人生の基本的な事実であり、暗号のすべてのユーザーが理解しなければならないものです。 「プードル」などの弱いパスワードを使用すると、攻撃者はパスワードを推測してデータを復号化することができます。 「hVztmdz28fNemDZnxj5YLjXz」などの強力なパスワードを使用する場合、データは当面の知識の範囲内で、予見可能な将来にわたって安全に保たれます。
元のポスターと回答とコメントで指摘された他のいくつかのポイントを明確にしたいと思います。
元の投稿では、ccryptが何に置き換わるかについて誤解があるようです。これはおそらく、ドキュメントのその部分を長い間更新していないためです。 （2001年に）ccryptが古いunix cryptプログラムの代わりになると書いたとき、私はcrypt（3）ライブラリ関数ではなくcrypt（1）プログラムを参照していました。 Crypt（1）は、少なくとも1979年以降Unixに存在していたパスワードベースのファイル暗号化プログラムでした（バージョン7にありました： http://man.cat-v.org/unix_7th/1/crypt ）、そして1980年代と1990年代を通してよく知られていました。それは、第二次世界大戦ですでに破られていたエニグマ暗号に基づく悪名高い弱いアルゴリズムを使用していました。一方、crypt（3）は、/ etc/passwordで使用される形式にパスワードをハッシュするライブラリ関数です。私の知る限り、crypt（3）には特に問題はなく、現在も使用されています。 Ccrypt（1）は、crypt（3）ではなく、crypt（1）の代替です。 ccryptがcrypt（3）よりも「優れている」かどうかを尋ねることは、まったく異なることを行うため意味がありません。ありがたいことに今日のcrypt（1）プログラムを誰も覚えていないことを考えると、おそらくドキュメントのその部分を更新するべきでしょう。
元の投稿では、ccryptがユーザーに間違ったパスワードを入力したときに通知するという事実と、これにより辞書攻撃が速くなるかどうかについての質問も出されます。その答えは、おそらく非常に小さな定数の要因によるものを除いて、これは辞書攻撃を速くしないということです。トーマスは彼の答えですでにこれをうまく説明しましたが、要点を強調するために、これを考慮してください：暗号化されたファイルがJPEGファイルであると仮定してください。すべてのJPEGファイルは、同じ3バイト、つまりff d8 ffで始まります。したがって、鍵の正当性が正しいかどうかを確認する非常に簡単なテストがすでにあります。最初のブロックを復号化し、ファイルがff d8 ffで始まるかどうかを確認するだけです。他のほとんどのファイル形式にも、このタイプの既知のプレーンテキストが含まれています。たとえば、すべてのPDFファイルは「％PDF」で始まります。ファイルがプレーンテキストファイルであるかどうかも簡単に確認できます。したがって、 ccryptがパスワード照合機能を提供するという事実は、とにかく攻撃を容易にしません。実際、ccryptの「照合」キーのチェックも100％正確ではありません。40億分の1の確率でランダムなキーは、正しいキーでなくてもテストに合格します。この機能は、誤ったキーを使用してファイルを誤って復号化することを防ぐために存在します（そのため、ファイル内のすべてのデータがゴミで上書きされます）。
概要：すべてのパスワードベースの暗号化ソフトウェアと同様に、ccryptは辞書攻撃の影響を受けます。ユーザーはこれを認識し、強力なパスワードを選択する必要があります。ただし、これらの攻撃のコストを一定の係数で増加させることで、安全性の低いパスワードの安全性を少し低くすることは逆効果になります。代わりに、最初に安全なパスワードを使用することが唯一の正しい応答です。 Thomas Porninの回答で提示された残りの分析の多くには欠陥があり、ccryptの実際の弱点は明らかにされていません。