Java Cryptography Extension的密鑰長度限制

Question

我知道Sun / Oracle JVM中的關鍵因為司法原因而受到限制。 但是據我所知， JCE（Java Cryptography Extension）的概念是用戶可以選擇它自己的安全提供程序來彌補這一限制。

出於這個原因，我試圖將Bounce Castle作為安全提供程序與Orcale JDK 1.7一起運行 。

為了弄清楚我使用此代碼的實際允許的keylegth：

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" );
}
}

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

但是當我通過切換到應用BC作為提供者時

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

它仍然向我顯示有限的密鑰長度（RSA除外），如下所示：

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

但是當我將JDK更改為openJDK時 ，我得到了這個輸出：

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

這令我感到驚訝，因為我的印象不是JDK，而是安全提供者限制密鑰長度。 但我的測試表明，無論我選擇哪個提供商，顯然JDK都會限制密鑰長度。

我的問題是：我有什么不對嗎？ 有沒有辦法釋放Oracle JDK的密鑰？

Answer 1

密鑰長度限制在JCE中確定，即在JRE中，而不是在提供者中。 JCE在將限制移交給提供者之前檢查限制。

對此的正確解決方案是安裝無限強度策略文件 。 雖然這可能是您的開發工作站的正確解決方案，但非技術用戶在每台計算機上安裝文件很快成為一個主要的麻煩（如果不是障礙）。 無法使用您的程序分發文件; 它們必須安裝在JRE目錄中（由於權限，它甚至可能是只讀的）。

Bouncy Castle確實提供了自己的API，它與JCE是分開的。 此API不強制執行任何密鑰長度限制。 這也不是一個理想的解決方案，因為API完全不同於JCE並且綁定到BC，而BC是一個額外的1MB庫，可以與您的程序一起分發。

最后，還有一個更詳細描述的反射解決方法 。

OpenJDK沒有任何密鑰長度限制，這就是為什么它們都只是Integer.MAX_VALUE 。