5

商用 Web アプリケーションで AES256 暗号化/復号化が必要です。現在のところ、鍵のサイズは 128 ですべて問題ありません。これは暗号学的に満足できるものではないため、ユーザーが手動で何かをインストールする必要なく、この問題を回避する最善の方法が私の問題です。

Oracle の無制限の管轄 jar ファイルを持っていますが、ユーザーの JRE/lib/security ディレクトリにあるこれらのファイルを古いバージョンと互換性があるかどうかはわかりません。明らかに、ユーザーの JRE を破損させたくありません。また、JRE セキュリティ ディレクトリへの書き込み権限がありますが、これらの権限を持たないユーザーもいると思います。

この問題を回避する簡単な方法はありますか? それとも、暗号化が弱いか、ユーザーにとって問題となる可能性のある手順で立ち往生していますか?

「制限解除」javax.crypto.JceSecurityの更新

@ntoskmlあなたは正しいです。getMaxAllowedKeyLengthは引き続き制限されたキー サイズを返しますが、暗号化はキー サイズ == 256 で成功します:)。強力な暗号化が利用できる場合は、テスト方法を更新し、キー サイズを設定します。ありがとう

>>> from javax.crypto import Cipher
>>> Cipher.getMaxAllowedKeyLength("AES")
128
>>> from java.lang import Class
>>> c = Class.forName("javax.crypto.JceSecurity")
>>> isRestricted = c.getDeclaredField("isRestricted")
>>> isRestricted.setAccessible(True)
>>> isRestricted.set(None, False)
>>> isRestricted.get(None)
False
>>> Cipher.getMaxAllowedKeyLength("AES")
128
>>> from javax.crypto import KeyGenerator
>>> kge = KeyGenerator.getInstance("AES")
>>> kge.init(256)
>>> aesKey = kgen.generateKey()
>>> c2 = Cipher.getInstance("AES")
>>> c2.init(Cipher.ENCRYPT_MODE, aesKey)
>>> c2.doFinal("test")
array('b', [-81, 99, -61, -51, 93, -42, -68, -28, 107, 59, -109, -98, -25, 127, 37, 23])

そしてJythonコンソール再起動後のテストケース

>>> # Reflection as above
>>> isRestricted.get(None)
True
>>> kge.init(256)
>>> aesKey = kge.generateKey()
>>> c2.init(Cipher.ENCRYPT_MODE, aesKey)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
        at javax.crypto.Cipher.checkCryptoPerm(Cipher.java:1011)
        at javax.crypto.Cipher.implInit(Cipher.java:786)
        at javax.crypto.Cipher.chooseProvider(Cipher.java:849)
        at javax.crypto.Cipher.init(Cipher.java:1213)
        at javax.crypto.Cipher.init(Cipher.java:1153)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)

java.security.InvalidKeyException: java.security.InvalidKeyException: Illegal key size or default parameters

ビンゴ:) @ntoskmlを共有してくれてありがとう

4

2 に答える 2

5

編集: この質問に対する最新の回答は次のとおりです:アプリケーションをデプロイするときに「無制限の強度」JCE ポリシー ファイルをインストールしないようにするにはどうすればよいですか?

数行のリフレクションを使用するだけで、キー サイズの制限を無効にすることができます。この方法は、相互運用性のために 256 ビット暗号化へのアクセスを必要とするプログラムで使用します。

private static void removeCryptographyRestrictions() {
    if (!isRestrictedCryptography()) {
        return;
    }
    try {
        java.lang.reflect.Field isRestricted;
        try {
            final Class<?> c = Class.forName("javax.crypto.JceSecurity");
            isRestricted = c.getDeclaredField("isRestricted");
        } catch (final ClassNotFoundException e) {
            try {
                // Java 6 has obfuscated JCE classes
                final Class<?> c = Class.forName("javax.crypto.SunJCE_b");
                isRestricted = c.getDeclaredField("g");
            } catch (final ClassNotFoundException e2) {
                throw e;
            }
        }
        isRestricted.setAccessible(true);
        isRestricted.set(null, false);
    } catch (final Throwable e) {
        logger.log(Level.WARNING,
                "Failed to remove cryptography restrictions", e);
    }
}

private static boolean isRestrictedCryptography() {
    return "Java(TM) SE Runtime Environment"
            .equals(System.getProperty("java.runtime.name"));
}

ただし、私たちのプログラムはアプレットではないため、アプレットがリフレクション API にアクセスできるかどうかはわかりません。

合法性についても疑問が残ります。その制限には理由があります。気になるなら弁護士に相談。

可能であれば、128 ビット キーに保つようにしてください。ムーアの法則を考慮したとしても、128 ビット AES を破るには何十億年もかかります。より長いキーは、現実の世界では何のメリットもありません。特に、キーがパスワードから派生している場合は、エントロピーが 256 ビットに近くありません。

于 2013-08-26T05:09:31.830 に答える
2

暗号化が弱いか、SunJCE に固執している場合、ユーザーにとって問題となる可能性のある手順で立ち往生しています。

明らかに、AES ライブラリのインポートに問題はありません Cipher。JCA に依存しない特定のソフトウェアがある場合は、たとえば、Bouncy Castle の軽量暗号 API を使用するようにそれを書き直すことができます。

Bouncy API 自体の他の多くの部分が JCE に依存していることに注意してください。軽量 API は、SunJCE よりも使い方が難しく、文書化もテストもされていません。

Bouncy Castle の軽量 API もかなり大きいです。必要のない多くの機能が含まれています。したがって、アプレットには大きすぎる可能性があります。その場合は、Bouncy Castle から必要な特定のクラスのみを含む新しいライブラリを作成することをお勧めします。幸いなことに、Bouncy Castle は非常に自由にライセンスされています。著作権表示などをきちんとしておけば、簡単に切り離すことができます。

于 2013-08-26T01:02:49.630 に答える