byte[]私のチームは、Javaで記述されたAndroidアプリケーションのコンテキストでバイナリデータ（として保存される）を暗号化するソリューションを開発する必要があります。暗号化されたデータはさまざまな方法で送信および保存されますが、その間、データの破損を排除することはできません。最終的には、別のAndroidアプリケーション（これもJavaで記述されています）がデータを復号化する必要があります。
暗号化アルゴリズムは、256ビットのキーを持つAESでなければならないことがすでに決定されています。ただし、どのAES実装および/または「モード」を使用するかについて、十分な情報に基づいて決定したいと思います。私はGCMモードと呼ばれるものについて読み、それを使っていくつかのテストを行いました（BouncyCastle / SpongyCastleを使用）が、AES-GCMが正確に何のためにあり、プレーンと比較して何を「購入」するのかは完全にはわかりません。 AES-考慮すべきトレードオフがあるかどうか。
これが私たちが持っている懸念/要件/質問のリストです：
パディング：暗号化する必要のあるデータは常に128ビットの倍数になるとは限らないため、AES実装/モードではパディングを追加する必要がありますが、必要な場合に限ります。によって提供されるような単純なAES実装で
javax.crypto.Cipherはそれができないという印象を受けましたが、初期のテストではそうなることが示されました。したがって、パディング要件自体は、「プレーンな」AESではなくGCMのようなものに頼る理由にはならないのではないかと思います。あれは正しいですか？認証：データ破損が発生したかどうかを確実に検出する方法が必要です。ただし、理想的には、誤ったキーを使用して復号化が試行された場合も検出する必要があります。したがって、これらの両方のケースを区別できるようにする必要があります。私が最初にGCMを検討することになった理由は、このStackoverflowの質問によるものでした。回答者の一人は、詳細な説明（コードは言うまでもなく）を提供していませんが、AES-GCMを使用してこの区別を行うことが可能であると示唆しているようです。 。
オーバーヘッドの最小化：暗号化されたデータの保存と送信のオーバーヘッドを制限する必要があります。したがって、特定のAES実装/モードの選択がオーバーヘッドの量に影響を与えるかどうか、およびどの程度影響するかを知りたいと思います。
暗号化/復号化のパフォーマンス：主要な懸念事項ではありませんが、特定のAES実装/モードの選択が、CPU時間とメモリフットプリントの両方の観点から、暗号化と復号化のパフォーマンスにどの程度影響するか疑問に思っています。
アドバイス、説明、コード例を事前に感謝します。
編集： delnanは、「プレーンAES」のようなものは存在しないことを有益に指摘しました。つまり、明確にするために、Javaの組み込みAESサポートを使用することを意味しました。
そのようです：Cipher localCipher = Cipher.getInstance("AES");