jsch 升级 0.2.x 版本对 bcprov-jdk 的依赖分析
背景
某应用使用 jsch 0.1.x 版本进行 SFTP 操作，某主机上连接时出现了com.jcraft.jsch.JSchException: Algorithm negotiation fail算法协商异常，解决思路是升级 jsch 为 0.2.x 版本，但是工程中又有两种 org.bouncycastle.crypto 包的实现，一种是第三方 bcprov-jdk，一种是自定义封装类种打包了 bcprov-jdk* 的内容。
结果直接更换为高版本的 jar ，工程还是报错，只是异常原因在于这个包冲突。到底这个包和 bcprov-jdk 是什么关系呢？
使用 Opus4.5 模型分析
这个目录 /Users/xxx/Downloads/jsch-0.2.24.jar 来分析它是否依赖了
bcprov-jdk15on
分析结果，根据分析 jsch-0.2.24.jar：
结论：jsch-0.2.24 对 bcprov-jdk 是可选依赖（optional），不是必需依赖。
证据：
- MANIFEST.MF 中的 Import-Package：
org.bouncycastle.crypto;version=“[1.79,2)”;resolution:=optional
org.bouncycastle.crypto.digests;version=“[1.79,2)”;resolution:=optional
org.bouncycastle.pqc.crypto.ntruprime;version=“[1.79,2)”;resolution:=optional
… - 所有 BouncyCastle 包都标记为 resolution:=optional
- JAR 包结构：
- com/jcraft/jsch/jce/ - 使用标准 JCE 的实现（AES, TripleDES 等）
- com/jcraft/jsch/bc/ - 使用 BouncyCastle 的实现（Ed25519, ChaCha20 等）
需要 BouncyCastle 的功能：
- Ed25519/Ed448 签名
- X25519/X448 密钥交换
- ChaCha20-Poly1305 加密
- SNTRUP761、ML-KEM 后量子加密
- Twofish、CAST128 等非标准算法
不需要 BouncyCastle 的功能：
- RSA、ECDSA 签名
- AES、3DES 加密
- 标准 Diffie-Hellman 密钥交换
如果你的 SSH 服务器只使用标准算法，可以不添加 bcprov 依赖。
分析过程
由于包冲突，想把自定义封装中的 SM4 工具算法重写一下，用 Claude Code 的 sonnet4.5 模型重写工具，并兼容之前自定义算法的内容，写了一下午出来的结果都不对，无法兼容之前版本加密的内容的解密。
核心是 SM4 算法的密钥要求16byte=128bit，自定义封装的算法中密钥给了 64byte 的但是能正常加密和解密。Sonnet4.5 写的代码总是不能做好这个密钥长度的统一。今天切换成 Opus4.5 后，给昨天一样的命令，一次就写出来了 SM4 工具，而且能完美兼容旧版本。
感觉提示词思路是一样的，「实现一个加解密的工具类，实现加密和解密。要求如下：密钥是 64字节的字符串xxx，能兼容之前加密的结果。 」
现在我理解了实现方式。让我创建 SM4Utils 工具类，使用
Bouncycastle（项目已有依赖）来实现与 Xxx.jar 兼容的 SM4 加密解密。确实实现了，而且还顺手把依赖这个工具类的空白引用给加上了。
启示录
安装了 OpenClaw 使用的是 MiniMax 的模型，ClaudeCode 使用的是 Sonnet 模型，相同的编码问题问这两种 Agent ，Claude Code 更胜一筹，尤其是脚本编写，Claude Code 写的代码更严谨。
此外，使用 OpenClaw 总感觉不安全，它没有任何中间过程的输出，然后就把事情给完成了，中间有没有失控，看不到；相比之下，ClaudeCode 每一步都有输出，有确认，更有掌控感！