AESは、製品レベルのソフトウェアに推奨される対称暗号ですか？
人気のある対称暗号の実装の多くをストレステストした後、ファイル暗号化用のアプリケーションレベルソフトウェアの開発を検討していました。 AES（GCM/CBC/CTR）、XChaCha20-Poly1305などの複数のアルゴリズムをサポートしたいのですが、パフォーマンスと安全な実装に関して、アプリケーションに強く推奨されている対称暗号を選択するとき、私は岐路に立っています。 。 AESは何年にもわたって試され、テストされており、今でも世界で最も人気のある対称暗号です。これは十分に文書化されており、さまざまな政府によって標準化されていますが（たとえばFIPS標準）、ハードウェアアクセラレーションが利用可能でない限り、安全に実装することは非常に困難です。 AESの純粋なソフトウェアバージョンは遅く、私のアプリケーションは多くのデバイスで同じパフォーマンスを達成できるはずです。また、AES GCMにはメッセージの最大サイズ制限が64 GBまであり、暗号化による認証が本当に必要でした。
AESとそのさまざまなモード（CTR HMAC SHA256など）を使い続けるべきか、それともXChaCha20やXSalsa20などの新しい対称暗号をPoly1305に採用すべきか簡単でソフトウェアに実装するのに安全であるか、しかし残念ながらまだ標準化されていませんか？
また、製品品質のソフトウェアで標準化された暗号の使用が推奨されるのはなぜですか？
逆の順序で質問に答える：
標準化された暗号を使用する理由優れたパフォーマンス、実装の合理的な複雑さなどを維持しながら、多くの可能な攻撃に対して安全な暗号を作成することは非常に困難です。たとえば、AESでご存知のように、標準化された暗号は、何年も試され、テストされてきました。それらはそれでも結局人気があるので、私たちはそのような暗号に大きな信頼を得ることができます。
XChaCha20などは、特にお客様の要件、誰が使用するかなどによっては、まだ製品品質のソフトウェアの準備ができていない可能性があると思います。致命的/深刻な欠陥が1年または2年後に発見され、何百万人ものユーザーがソフトウェアを使用している確率は低く、標準化された暗号ほど小さくはありません。
実際、実装の複雑さに懸念があり、実装に間違いを犯す恐れがある場合、その懸念は有効ですが、1つのオプションは、AES GCMなどの十分にテストされた特定のライブラリ/実装を使用して軽減することです物事の実装側のリスク。