ウェブクリプト

クライアント側（ブラウザ）JavaScriptの暗号化に関する懸念事項については、以下で詳しく説明します。これらの懸念事項のうち1つを除いて、すべては、WebCrypto API、現在はかなりよくサポートされている。

オフライン アプリの場合でも、安全なキーストアを設計して実装する必要があります。

補足：Node.jsを使用している場合は、WebCrypto/ノードまたは組み込み暗号API。

ネイティブ JavaScript 暗号化 (WebCrypto 以前)

主な懸念は、コンピューターに物理的にアクセスできる誰かがlocalStorageサイトの情報を読み取ることであり、そのアクセスを防止するために暗号化が必要であると考えられます。

誰かが物理的にアクセスできる場合、読み取り以外の悪質な攻撃を受ける可能性もあります。これには、キーロガー、オフライン スクリプトの変更、ローカル スクリプトの挿入、ブラウザー キャッシュ ポイズニング、DNS リダイレクトなどが含まれます (ただし、これらに限定されません)。これらの攻撃は、ユーザーがマシンが侵害された後にそのマシンを使用する場合にのみ機能します。ただし、このようなシナリオで物理的にアクセスできるということは、より大きな問題が発生することを意味します。

したがって、ローカルの暗号が価値を持つのは、マシンが盗まれた場合のみという限定されたシナリオであることに留意してください。

必要な機能を実装しているライブラリは存在します。例えば、スタンフォード Javascript 暗号ライブラリただし、固有の弱点があります（@ircmaxell の回答のリンクで言及されているように）。

1. エントロピー/乱数生成の欠如;
2. 安全なキーストアがないため、秘密鍵をローカルに保存する場合、またはサーバーに保存する場合（オフライン アクセスを禁止する）は、パスワードで保護する必要があります。
3. 安全な消去の欠如;
4. タイミング特性の欠如。

これらの弱点はそれぞれ、暗号侵害のカテゴリに対応しています。言い換えれば、名前は「暗号」であっても、実際には目指す厳密さをはるかに下回るものになります。

とはいえ、保険数理評価は「Javascript の暗号は弱いので使用しないでください」というほど簡単ではありません。これは推奨ではなく、あくまで警告であり、上記の弱点の危険性、直面するベクトルの頻度とコスト、および障害が発生した場合の緩和策または保険の能力を完全に理解する必要があります。Javascript の暗号は、その弱点にもかかわらず、危険性を軽減する可能性がありますが、技術的能力が限られている泥棒に対してのみです。ただし、その情報を狙う断固とした有能な攻撃者に対しては、Javascript の暗号は価値がないと想定する必要があります。実装に固有の多くの弱点がわかっている場合、データを「暗号化されている」と呼ぶのは誤解を招くと考える人もいます。つまり、技術的な危険性はわずかに軽減できますが、開示による金銭的な危険性は増加します。もちろん、状況はそれぞれ異なります。そして、技術的な危険性を金銭的な危険性に減らす分析は簡単ではありません。以下に、わかりやすい例えを示します。一部の銀行では弱いパスワードが要求される固有のリスクがあるにもかかわらず、弱いパスワードによる損失のリスクは、強力なパスワードをサポートするためのエンドユーザーのコストよりも低いため、セキュリティは確保されています。

�� 最後の段落を読んで「インターネット上のブライアンという人が、Javascript 暗号を使用できると言っている」と思った場合は、Javascript 暗号を使用しないでください。

質問で説明されているユースケースでは、ユーザーがローカル パーティションまたはホーム ディレクトリを暗号化し、強力なパスワードを使用する方が合理的であると思われます。このタイプのセキュリティは、一般的に十分にテストされ、広く信頼されており、一般的に利用可能です。