怎么通过 String.regionMatches() 对比两个加密文本的特定指纹段是否完全一致

先说一个核心判断：String.regionMatches() 这个方法，在密码学安全的场景里，其实并不适合用来比对加密文本的“指纹段”。原因很简单：它不是一个恒定时间的比较操作（timing-secure），因此存在被时序攻击利用的风险。如果你的目标是验证加密输出——比如哈希值、数字签名、密钥派生结果中某一段是否完全一致——那正确的做法是用恒定时间比较算法，而不是直接用 regionMatches()。

为什么 regionMatches() 不适合加密指纹比对

问题出在这个方法的执行机制上：它一旦遇到第一个不匹配的字符，就会立刻返回 false。也就是说，如果第一个字符就不同，它几乎瞬间就能给出结果；如果前面几个字符都匹配上了，直到第8个字符才发现差异，那它花的时间就会更长。这种时间差异，在高精度的攻击者面前，就成了泄漏信息的通道——通过反复测量比对耗时，就能逐步推算出匹配的长度，从而一点点恢复出敏感值，比如 HMAC 签名、AES-GCM 的认证标签，或者 PBKDF2 的输出片段。在密码学场景里，这属于严重漏洞。

换句话说，哪怕你只比对特定的一段（比如哈希值的前8个字节），只要这段数据承载了认证或完整性语义，就必须防范时序侧信道攻击。这不是杞人忧天，而是行业共识。

正确做法：用恒定时间字节数组比较

加密指纹本质上就是二进制数据。正确的流程，是先把它从字符串形式解码成真正的字节数组，然后再用恒定时间的方法逐字节比对。具体来说：

• 如果指纹是以十六进制字符串形式存在的（比如 "a1b2c3d4..."），那就用 Hex.decode()（Apache Commons Codec）或者 ja va.util.HexFormat（Ja va 17+）把它转成 byte[]
• 如果指纹是 Base64 格式的（比如 "oTKj1M..."），就用 ja va.util.Base64.getDecoder().decode()
• 然后调用恒定时间比较工具：
  – Ja va 17+ 推荐直接使用 MessageDigest.isEqual(byte[], byte[])
  – 更早的版本，可以用手写实现，或者使用像 org.bouncycastle.crypto.params.KeyParameter.equals() 这样经过审计的代码库
  – 如果自己实现，关键是要遍历全部字节，把每一次的异或结果累加起来，最后判断总和是否为 0。绝不能中途跳出循环。

示例：安全比对 Hex 字符串表示的指纹前 16 字节

假设你有两个指纹字符串 f1 = "a1b2c3d4e5f678901234567890abcdef" 和 f2 = "a1b2c3d4e5f67890fedcba9876543210"，现在想比对它们前 16 个字节（即前 32 个 hex 字符）是否一致。正确的做法是：

• 先分别用 HexFormat.of().parseHex(f1.substring(0, 32)) 和 f2.substring(0, 32)，得到两个 byte[16] 数组
• 然后调用 MessageDigest.isEqual(bytes1, bytes2)——这个方法内部已经保证了恒定时间的比较逻辑

这里需要特别强调一点：千万不要偷懒，直接用 regionMatches() 去比对原始字符串，哪怕它们看起来只是 ASCII 十六进制字符。因为比较逻辑本身就不是恒定时间的，风险依然存在。

补充提醒：避免常见误用

• 不要用 String.equals() 或 regionMatches() 来做任何与密码学相关的相等判断——哪怕是临时调试也不建议，习惯很重要。
• 确保要比对的段落长度一致。如果长度不同，直接返回 false 是没问题的，但要注意：这个长度判断本身也应该是恒定时间的。最简单的做法是先比较长度，再统一进入字节循环，或者把两个数组都补齐到固定长度再比对。
• 如果指纹来自不可信来源，比如 HTTP 请求头里的参数，那还需要先校验它的格式是否合法（比如 hex 字符数是不是偶数，字符集合是不是正确的）。否则解码时可能抛出异常，影响服务稳定性。