Java 加密扩展的密钥长度限制

Key length limit with Java Cryptography Extension

提问by Randy

I am aware that the keylenght in the Sun/Oracle JVM is limited for judical reasons. However as far as I understood the concept of the JCE (Java Cryptography Extension)is that a user can choose it's own security provider to compensate this limitation.

我知道由于司法原因，Sun/Oracle JVM 中的密钥长度是有限的。然而，据我所知，JCE（Java 加密扩展）的概念是用户可以选择自己的安全提供者来弥补这一限制。

For this reason I am trying to operate the Bounce Castleas security provider in conjunction with the Orcale JDK 1.7.

出于这个原因，我试图将Bounce Castle作为安全提供者与Orcale JDK 1.7结合使用。

In order to figure out the actual allowed keylegths I am using this code:

为了找出实际允许的keylegths我使用这个代码：

import org.bouncycastle.jce.provider.BouncyCastleProvider;

import javax.crypto.Cipher;
import java.security.GeneralSecurityException;
import java.security.Provider;
import java.security.Security;

public class JCETest {
public static void main( String[] args ) throws GeneralSecurityException
{

    BouncyCastleProvider bouncyCastleProvider = new BouncyCastleProvider();
    Security.addProvider(bouncyCastleProvider);

    System.out.println( "\nSecurity-Provider:" );
    for( Provider prov : Security.getProviders() ) {
        System.out.println( "  " + prov + ": " + prov.getInfo() );
    }
    System.out.println( "\nMaxAllowedKeyLength (for '" + Cipher.getInstance("AES").getProvider() + "' using current 'JCE Policy Files'):\n"
            + "  DES        = " + Cipher.getMaxAllowedKeyLength( "DES"        ) + "\n"
            + "  Triple DES = " + Cipher.getMaxAllowedKeyLength( "Triple DES" ) + "\n"
            + "  AES        = " + Cipher.getMaxAllowedKeyLength( "AES"        ) + "\n"
            + "  Blowfish   = " + Cipher.getMaxAllowedKeyLength( "Blowfish"   ) + "\n"
            + "  RSA        = " + Cipher.getMaxAllowedKeyLength( "RSA"        ) + "\n" );
}
}

The output for the Orcale JDK 1.7and it's build in providers is:

输出为ORCALE JDK 1.7中提供者，它的构建是：

Security-Provider:
  SUN version 1.7: SUN (DSA key/parameter generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP, Collection CertStores, JavaPolicy Policy; JavaLoginConfig Configuration)
  SunRsaSign version 1.7: Sun RSA signature provider
  SunEC version 1.7: Sun Elliptic Curve provider (EC, ECDSA, ECDH)
  SunJSSE version 1.7: Sun JSSE provider(PKCS12, SunX509 key/trust factories, SSLv3, TLSv1)
  SunJCE version 1.7: SunJCE Provider (implements RSA, DES, Triple DES, AES, Blowfish, ARCFOUR, RC2, PBE, Diffie-Hellman, HMAC)
  SunJGSS version 1.7: Sun (Kerberos v5, SPNEGO)
  SunSASL version 1.7: Sun SASL provider(implements client mechanisms for: DIGEST-MD5, GSSAPI, EXTERNAL, PLAIN, CRAM-MD5, NTLM; server mechanisms for: DIGEST-MD5, GSSAPI, CRAM-MD5, NTLM)
  XMLDSig version 1.0: XMLDSig (DOM XMLSignatureFactory; DOM KeyInfoFactory)
  SunPCSC version 1.7: Sun PC/SC provider
  BC version 1.46: BouncyCastle Security Provider v1.46

MaxAllowedKeyLength (for 'SunJCE version 1.7' using current 'JCE Policy Files'):
  DES        = 64
  Triple DES = 128
  AES        = 128
  Blowfish   = 128
  RSA        = 2147483647

But when I apply BC as provider by switching to

但是当我通过切换到 BC 作为提供者时

Cipher.getInstance("AES", bouncyCastleProvider).getProvider()

Cipher.getInstance("AES", bouncyCastleProvider).getProvider()

It still shows me the limited key length (except for RSA) like this:

它仍然向我显示有限的密钥长度（RSA 除外），如下所示：

MaxAllowedKeyLength (for 'BC version 1.46' using current 'JCE Policy Files'):
  DES        = 64
  Triple DES = 128
  AES        = 128
  Blowfish   = 128
  RSA        = 2147483647

But when I change the JDK to openJDK, I get this output:

但是当我将 JDK 更改为openJDK 时，我得到以下输出：

MaxAllowedKeyLength (for 'BC version 1.46' using current 'JCE Policy Files'):
  DES        = 2147483647
  Triple DES = 2147483647
  AES        = 2147483647
  Blowfish   = 2147483647
  RSA        = 2147483647

This astonishes me since I was under the impression that not the JDK but the security-provider limiting the key length. But my tests are showing that obviously the JDK is limiting the key length, no matter which provider I choose.

这让我感到惊讶，因为我的印象是限制密钥长度的不是 JDK，而是安全提供商。但是我的测试表明，无论我选择哪个提供者，JDK 显然都限制了密钥长度。

My question is: Did I got something wrong? Is there a way to unleash the keyleght with the Oracle JDK?

我的问题是：我做错了什么吗？有没有办法用 Oracle JDK 释放密钥？

回答by ntoskrnl

The key length limits are determined in the JCE, that is in the JRE, not in the provider. JCE checks the limits before it hands over to the provider.

密钥长度限制在 JCE 中确定，即在 JRE 中，而不是在提供者中。JCE 在移交给提供者之前检查限制。

The correct solution to this is to install the unlimited strength policy files. While this is probably the right solution for your development workstation, it quickly becomes a major hassle (if not a roadblock) to have non-technical users install the files on every computer. There is no wayto distribute the files with your program; they must be installed in the JRE directory (which may even be read-only due to permissions).

对此的正确解决方案是安装无限强度策略文件。虽然这可能是您的开发工作站的正确解决方案，但让非技术用户在每台计算机上安装文件很快就会成为一个主要的麻烦（如果不是障碍的话）。有没有办法来分发与您的程序文件; 它们必须安装在 JRE 目录中（由于权限，该目录甚至可能是只读的）。

Bouncy Castle does provide its own API though, which is separate from the JCE. This API does not enforce any key length limits. This is not an ideal solution either, as the API is totally different from the JCE and bound to BC, and BC is an extra 1MB library to distribute with your program.

不过，Bouncy Castle 确实提供了自己的 API，它与 JCE 是分开的。此 API 不强制执行任何密钥长度限制。这也不是一个理想的解决方案，因为 API 与 JCE 完全不同并且绑定到 BC，而 BC 是一个额外的 1MB 库，可以与您的程序一起分发。

Finally, there is also a reflection workaround described herein more detail.

最后，这里还详细介绍了一种反射解决方法。

OpenJDK does not have any key length limits, which is why they are all simply Integer.MAX_VALUE.

OpenJDK 没有任何密钥长度限制，这就是为什么它们都是简单的Integer.MAX_VALUE.