简而言之，差异的原因是模式＃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哈希。
