简而言之,差异的原因是模式#1和#2中的PBKDF2算法使用PKCS#5 v2方案2(PKCS5S2)来生成迭代密钥,但是模式#3中用于“
PBEWITHHMACSHA1”的BouncyCastle提供程序使用了PKCS#而是使用12
v1(PKCS12)算法。这些是完全不同的密钥生成算法,因此您将获得不同的结果。
下面将详细说明为何如此以及为什么您得到不同大小的结果。
首先,在构造JCE
KeySpec时,keyLength参数仅向提供者“偏好”表示所需的密钥大小。从API文档:
注意:这用于指示密钥长度可变的密钥对密钥长度的偏好。实际密钥大小取决于每个提供程序的实现。
从JCEPBEKey的来源来看,Bouncy
Castle提供程序似乎并不尊重此参数,因此,在使用JCE API时,您应该期望从使用SHA-1的任何BC提供程序获取160位密钥。
您可以通过以编程方式访问测试代码中
getKeySize()返回的
keybc变量上的方法来确认这一点:
Key keybc = factorybc.generateSecret(keyspecbc);// ...Method getKeySize = JCEPBEKey.class.getDeclaredMethod("getKeySize");getKeySize.setAccessible(true);System.out.println(getKeySize.invoke(keybc)); // prints '160'
现在,要了解“
PBEWITHHMACSHA1”提供程序的含义,可以在BouncyCastleProvider的源代码中找到以下内容:
put("SecretKeyFactory.PBEWITHHMACSHA1", "org.bouncycastle.jce.provider.JCESecretKeyFactory$PBEWithSHA");
JCESecretKeyFactory.PBEWithSHA的实现如下所示:
public static class PBEWithSHA extends PBEKeyFactory{ public PBEWithSHA() { super("PBEwithHmacSHA", null, false, PKCS12, SHA1, 160, 0); }}
您可以在上方看到该密钥工厂使用PKCS#12
v1(PKCS12)算法来生成迭代密钥。但是,您要用于密码哈希处理的PBKDF2算法改为使用PKCS#5
v2方案2(PKCS5S2)。这就是为什么您获得不同结果的原因。
我快速浏览了注册的JCE提供程序
BouncyCastleProvider,但是根本看不到 任何
使用PKCS5S2的密钥生成算法,更不用说将其与HMAC-SHA-1一起使用了。
因此,我想您要么会使用Sun实现(上面的模式1)并失去在其他JVM上的可移植性,要么直接使用Bouncy
Castle类(上面的模式2)并在运行时需要BC库。
无论哪种方式,您都应该切换到160位密钥,这样就不会不必要地截断生成的SHA-1哈希。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)