データストレージ用の自己復号HTMLファイルはどの程度安全ですか？
私は最近JavaScriptに出くわしました 自己復号化アーカイブ 。ポータブルパスワードストレージツールとして使用するのに十分安全ですか？著者はさらに 挑戦した を解読しました。
少なくとも著者は 彼の暗号化のしくみ についてかなり明確なページを書いた。それにもかかわらず、これはかなり古いスタイルの自家製ストリーム暗号のように見えますが、そのようなシステムのほとんどが完全に破壊されているため、これは良いニュースではありません。これは、基本的なLFSRサブシステム（キーに依存する多項式を持つ2つのLFSR。「逆方向」で動作する多項式についてのビットは、このサブシステムが完全に線形であるため、赤ニシンです）と、非LFSRとして機能する別のLFSRで構成されるようです。 -線形選択エンジン。おおよそそのように見え、無視できない暗号解読耐性を提供するように見えるいくつかの選択デザインがあります（例 Alternate Step Generator ）が、これには代償が伴います。つまり、かなり多くのものが必要です。 n2を達成したい場合は、状態の内部ビットんセキュリティレベル。また、そのようなデザインの多くは脆弱であることが判明しました。
以下の特性の組み合わせに基づいて、暗号アルゴリズムの耐性を信頼できます。
- デザイナーはアルゴリズムの設計が非常に得意であることが知られています（例：彼の名前は Rivest ）。
- 注目を集めた会議で公開されたり、大規模に展開されたりするなど、デザインは広く知られるようになりました。
- 数年が経ち、誰も問題を発見しなかった。
このデザインは、3つの点で少し欠けています。
編集：気づきませんでした（朝はコーヒーがもっと必要です）が、生成されたストリームは特定のパスワードに対して確定的です。つまり、同じパスワードでtwoアーカイブを暗号化すると、悪名高い「2倍パッド」の状況になり、基本的には失われます。
もう1つのポイントは、パスワードがMD5の呼び出しのペアが1つだけのキーに導出されることです。 MD5は非常に高速です。優れているが、既製でまったく高価ではないGPUは、MD5を約10億/秒の速度で評価できます。暗号化されたデータの最初のバイトが攻撃者によって推測された場合（クリアテキストはJavaScriptであると想定されているため、最初のバイトはおそらく「var」または「function」です）、全体辞書攻撃、別名「パスワードの全数検索」に対して脆弱です（一致が見つかるまで潜在的なパスワードを試行します）。 is辞書攻撃を無効にする大きな脂肪のランダムなパスワードを持つことが可能であり、人間の脳はそれでもいくらかの努力でそれを覚えることができました。しかし、ほとんどのパスワードはその点で弱いです。また、無塩：特定のパスワードに対して、常に同じストリームを取得します。したがって、潜在的なパスワードごとにストリームの最初のバイトを事前計算し、その後インスタンスをクラックすることは、テーブル内のいくつかのルックアップの問題になります（テーブルは Rainbow table よりコンパクトな保管のため）。
パスワード処理の部分では、このスキームは明らかに弱いです。
ユースケースにも疑問があります。これはユーザーがパスワードを入力するJavascriptコードであるため、アクティブな攻撃に対して脆弱です。アクティブな攻撃者はJavascriptコードを変更するだけで、ユーザーがパスワードを入力すると、パスワードのコピーもどこかに記録されます（例：復号化されたデータ（Javascript自体であるはずです）は、非表示の<img>タグを出力する追加のコードスニペットを取得します。このタグは、攻撃者が制御するサーバーを指し示し、パスワードをエンコードしています）。
この種のアクティブな攻撃に対抗するためのソリューションは既知であり、それがSSLです。 「自己復号化アーカイブ」はHTTPS経由でのみ提供されます。しかし、HTTPSを使用する場合、なぜ自己復号化が必要になるのでしょうか。代わりに、パスワードでユーザーを適切に認証した後でのみ、サーバーに機密性の高いJavascriptを提供させます。これは非常に一般的なモデルであり、既存のWebサーバーがそのまま実装します。オフラインの辞書攻撃を阻止するため、強力です（外部から、攻撃者はGPUの最大速度で「パスワードを試す」ことができません。それぞれの推測についてサーバーに尋ねると、サーバーは望みどおりにゆっくりと応答できます。
概要：このコードを使用してagainstをお勧めします。少なくとも、SDAの設計者は文書化に立派な努力を払っており、正気であるように見えます。正気だけでは、インターネット上の暗号設計者の群衆の中で彼は少数派になります。
これらすべてのタイプの問題は、どれほど安全であるかを実際に決定できないことです。私たちが代わりに行うことは、多数の経験者によって長い間テストされてきたものにある程度の信頼を置くことです（@ThomasPorninはこれについて優れた答えを持っています。これを試して、リンクを見つけます）-これがおそらく著者です彼は挑戦をしました：彼はそれがテストされることを望みます。
これは安全なアルゴリズムを使用する可能性がありますが、実装に弱点がある場合、安全ではない可能性があります。
要約すると、安全なSDAが本当に必要な場合は、リスクが低くなる可能性が高いため、試行錯誤したSDAを使用することをお勧めします。ただし、このコードの背後にあるコードを確認して、使用量が十分に少ないリスクを評価できる場合は、目的に応じて問題ないかもしれません。
（申し訳ありませんが少し不確かですが、その多くは...）
私は一般に、コードをレビューできないものや、オンラインで暗号化を行わなければならないようなものは避けます。多分それはここではそうではないかもしれませんが、オンラインでのみ利用できる新しい暗号化またはステガノグラフィアルゴリズムを以前から目にしてきました。それは、そこにいる人々が暗号化/非表示にしたいデータを収集するハニーポットでした。