关于Apache PDFBox使用SHA-1的安全性及替代方案的技术问询

嘿，针对你在用PDFBox做数字签名时碰到SHA-1被安全扫描器标记的问题，我来逐个拆解你的疑问：

为什么PDFBox还在使用SHA-1？ #

PDFBox保留SHA-1主要是为了兼容旧版PDF生态：

• 早期PDF规范（比如PDF 1.6及之前）里，部分文档结构校验、内部对象哈希逻辑是基于SHA-1设计的，PDFBox要能正常读写这些历史文档，就必须保留对SHA-1的支持
• 很多遗留系统生成的PDF用的是SHA-1签名，PDFBox需要能验证这类签名的有效性，所以不能直接移除SHA-1的实现

SHA-1是用于数字签名还是仅内部哈希？ #

SHA-1在PDFBox里有两类明确的使用场景：

• 内部非敏感场景：比如文档元数据校验、临时数据的完整性校验、PDF对象的引用哈希，这些场景不需要抗碰撞的强哈希算法，SHA-1的性能足够用，也不会有安全风险
• 数字签名相关场景：仅用于验证旧的SHA-1签名PDF，而生成新签名的默认逻辑里，PDFBox早就切换到SHA-256及以上的算法了——只要你没手动在代码里指定SHA1作为签名哈希，新生成的签名根本不会碰SHA-1

生产环境使用是否安全？ #

得分具体情况判断：

• 如果你只是用PDFBox处理普通文档、验证旧签名，没有用它生成新的SHA-1签名，那完全安全。内部使用SHA-1的场景都不涉及密码学敏感操作，不存在碰撞攻击的风险
• 要是你手动指定了SHA-1来生成新签名，那确实有严重安全问题——SHA-1已经被证实可以被碰撞攻击，这类签名既过不了合规要求，也没法保证文档的真实完整性

应该替换成SHA-256吗？ #

• 如果你是生成新的数字签名：必须替换！别手动指定SHA1，PDFBox默认就用SHA-256，你也可以在签名代码里明确指定算法，比如用MessageDigest.getInstance("SHA-256")，或者通过PDFBox的签名API设置哈希算法参数，确保万无一失
• 如果你是处理旧文档或内部哈希逻辑：完全没必要替换，强行修改反而会导致旧文档解析失败、旧签名验证出错，引入兼容性问题

另外补充下关于安全扫描器的小建议：如果扫描器只是检测到PDFBox代码里存在SHA-1的实现，这属于典型的误报——你可以给扫描器加个白名单规则，说明这是兼容历史场景的必要代码，你的业务逻辑里并没有用SHA-1生成新签名。

备注：内容来源于stack exchange，提问作者blinkbink