初期化ベクトルとソルトは、秘密にしておく必要がないという理由だけで、鍵ではなくそのように呼ばれます。そのようなデータを暗号化/ハッシュ化された要素と一緒にエンコードすることは安全であり、慣習的です。
IV またはソルトが必要とするのは、特定のキーまたはパスワードで一度だけ使用することです。一部のアルゴリズム (CBC 暗号化など) では、IV をランダムに選択し、均一な確率と暗号学的に強力な乱数ジェネレーターを使用することによって、いくつかの追加要件が満たされる場合があります。ただし、機密性は IV またはソルトに必要なプロパティではありません。
対称暗号化がセキュリティを提供するのに十分であることはめったにありません。暗号化はそれ自体で、攻撃者が監視するが干渉しない受動的攻撃から保護します。アクティブな攻撃から保護するには、何らかの認証も必要です。SJCL は、暗号化と認証を組み合わせた CCM または OCB2 暗号化モードを使用するため、問題ありません。「認証強度」は、暗号化されたテキスト内の認証専用のフィールドの長さ (ビット単位) です。「64 ビット」の強度は、攻撃者がメッセージを変更しようとする最大確率が 2 -64であることを意味します。認証メカニズムによって検出されずに成功すること (そして、試みなければ成功したかどうかを知ることはできません。つまり、キー/パスワードを知っている人に変更されたメッセージが送信されます)。ほとんどの目的にはこれで十分です。より大きな認証強度は、(ほぼ) 同じ量だけ、より大きな暗号文を意味します。
私は実装を見ていませんが、ドキュメンテーションから、SJCL の作成者は自分たちの取引を理解しており、適切に処理を行っているようです。使用することをお勧めします。
パスワードと Javascript に関する通常の警告を思い出してください。
Javascript は、クライアント側で実行されるコードですが、サーバーからダウンロードされます。これには、何らかの方法でダウンロードの完全性が保護されている必要があります。そうしないと、攻撃者が独自のコードの一部を挿入する可能性があります。たとえば、ユーザーが入力したパスワードのコピーをどこかに記録する単純なパッチなどです。実際には、これは SJCL コードが SSL/TLS セッション (つまり HTTPS) を介して提供される必要があることを意味します。
ユーザーは人間であり、人間はパスワードの選択が苦手です。それは人間の脳の限界です。さらに、人間の脳は多かれ少なかれ変化し続ける一方で、コンピューターはますます強力になり続けています。これにより、パスワードは辞書攻撃、つまりパスワードの徹底的な検索に対してますます弱くなります (攻撃者は「ありそうな」パスワードを試すことでユーザーのパスワードを推測しようとします)。SJCL によって生成された暗号文は、オフライン辞書攻撃で使用できます。攻撃者は、サーバーに対してパスワードをチェックすることなく、自分のコンピューターでパスワードを「試す」ことができ、自分のコンピューティング能力によってのみ制限されます。SJCL には、オフライン辞書攻撃をより困難にするいくつかの機能が含まれています。
- SJCL はソルトを使用し、コストの共有を防ぎます (通常は「事前計算済みテーブル」、特に特別な種類の事前計算済みテーブルである「レインボー テーブル」として知られています)。少なくとも攻撃者は、攻撃されたパスワードごとに辞書検索の全額を支払う必要があります。
- SJCL は、キーを生成するためにソルトをパスワードで何度もハッシュすることにより、ソルトを繰り返し使用します。これを SJCL では「パスワード強化要素」と呼んでいます。これにより、クライアントにとってパスワードからキーへの変換がより高価になりますが、攻撃者にとっても重要な点です。キー変換を 1000 倍長くすると、ユーザーはおそらく 0.5 秒待たなければならないことになります。ただし、攻撃者のコストも 1000 倍になります。