web-dev-qa-db-ja.com

java.security.NoSuchAlgorithmException：AES / ECB / PKCS7PADDINGをサポートするプロバイダーが見つかりません

AESアルゴリズムを使用してデータを暗号化しようとしていました。ただし、次の例外が発生しました。

Java.security.NoSuchAlgorithmException:
    Cannot find any provider supporting AES/ECB/PKCS7PADDING

誰かがこの問題の解決策を知っていますか？私のJDKのバージョンは1.7です。

javasecurityencryptionaesjce
21
Suby Lee

ブロック暗号の使用のためにPKCS＃7パディングを指定する必要はありません。 PKCS＃5パディングを指定します。 PKCS＃5はブロック暗号で使用するために指定されていますが、PKCS＃7は使用されていません（S/MIMEなどのさまざまな場所で使用されています）。 PKCS＃5とPKCS＃7は実際にはまったく同じ種類のパディングを指定します（同じです！）が、このコンテキストで使用される場合は＃5と呼ばれます。 :)

したがって、"AES/ECB/PKCS7PADDING"の代わりに、"AES/ECB/PKCS5PADDING"が必要です。これは、Javaプラットフォームのすべての実装がサポートする必要がある暗号化実装です。Cipherクラスのドキュメント を参照してください 詳細については。

36
user121356

PKCS＃5およびPKCS＃7暗号化標準のテキストを含む問題の非常に包括的な説明については、 here をご覧ください。

PKCS＃5パディングは、1〜8バイトのパディングを意味します。パディングバイト自体には、バイトとしてエンコードされたパディングバイトの量が含まれています。 PKCS＃5パディングはDESに指定されましたが、8バイトのブロックサイズのブロック暗号に適しています。

現在、DES仕様とパスワードベースの暗号化のPKCS＃5仕様でさえも先行し、Javaかなり長い間。AESは2002年にのみ標準化されました。 Javaおよび偶数Java 2が導入されました。したがって、（triple）DESおよびPKCS＃5パディングが=に統合されましたJava AESが登場する前。

Java-より正確には、Sun JCEプロバイダーは、16バイトのブロックサイズのパディングメソッドを必要とするAES機能を取得しました。PKCS＃7は、このパディングメソッドを指定します PKCS＃5 padding と同じですが、ブロックサイズが2〜255バイト（ゼロベースの符号なし整数をエンコードする場合の最大値）に定義されている点を除きます。 "PKCS5Padding"。したがって、新しい名前を導入する代わりに、"PKCS5Padding"は単に再利用されました。

これで、Sunプロバイダーは"PKCS7Padding" PKCS＃5のパディングは単に間違っています。これはJavaネーミングの問題ではなく、暗号化プロトコルを実装したり、他のアプリケーションをJavaに移植しようとする開発者にとっての問題です。ただし、今のところ、"PKCS5Padding" の代わりに "PKCS7Padding"。

3
Maarten Bodewes

aES/ECB/PKCS7Paddingを使用する場合、弾力がある城はhtをサポートします tp：//www.bouncycastle.org/specifications.html

2
kapil das