本文详解在使用 Bouncy Castle 实现 AES-CMAC 签名时，如何将 32 位十六进制字符串（如 "A1B2C3D4E5F678901234567890ABCDEF"）正确解析为 16 字节密钥，避免因 UTF-8 编码或符号扩展导致的跨语言（Java/C#）签名不一致问题。
本文详解在使用 bouncy castle 实现 aes-cmac 签名时，如何将 32 位十六进制字符串（如 `"a1b2c3d4e5f678901234567890abcdef"`）正确解析为 16 字节密钥，避免因 utf-8 编码或符号扩展导致的跨语言（java/c#）签名不一致问题。
在基于 AES-CMAC 的消息认证场景中，密钥通常以十六进制字符串形式提供（例如长度为 32 的字符串，对应 16 字节 AES-128 密钥）。一个常见误区是直接对原始字符串调用 String.getBytes(StandardCharsets.UTF_8) —— 这会将每个 ASCII 字符（如 'A', '1'）按 UTF-8 编码为独立字节，最终生成 32 字节的错误密钥，而非预期的 16 字节二进制密钥。
正确做法是：将字符串两两分组，每组视为一个两位十六进制数（如 "A1" → 十进制 161 → 字节 (byte) 0xA1），逐组解析为无符号字节值。Java 中 byte 类型虽为有符号，但 Integer.parseInt(s, 16) 返回 int，强制转为 byte 后高位自动截断，恰好等价于 C# 中 Convert.ToByte(s, 16) 的行为，从而保证跨平台一致性。
以下是推荐的工具方法实现：
public static byte[] stringToByteHexpairs(String input) {
if (input == null || input.length() % 2 != 0) {
throw new IllegalArgumentException("Hex string must have even length");
}
byte[] output = new byte[input.length() / 2];
for (int i = 0; i <p>使用示例（完整 CMAC 签名流程）：</p><pre class="brush:php;toolbar:false;">String KEY_HEX = "A1B2C3D4E5F678901234567890ABCDEF"; // 32-char hex string
String MESSAGE_HEX = "0001020304050607"; // 同样需 hex 解析的原始消息（可选）
// ✅ 正确：将 hex 字符串转为二进制密钥和消息
byte[] keyBytes = stringToByteHexpairs(KEY_HEX);
byte[] messageBytes = stringToByteHexpairs(MESSAGE_HEX);
KeyParameter keyParam = new KeyParameter(keyBytes);
AESEngine aes = new AESEngine();
CMac mac = new CMac(aes);
mac.init(keyParam);
mac.update(messageBytes, 0, messageBytes.length);
byte[] macResult = new byte[mac.getMacSize()];
mac.doFinal(macResult, 0);
// ✅ 标准化输出：CMAC 结果也常以大写十六进制字符串返回
String signature = bytesToHexString(macResult); // e.g., "D4F3C2B1A09F8E7D..."⚠️ 关键注意事项：
- 不要使用 KEY.getBytes(UTF_8)：它生成的是字符编码字节流（如 'A'→65，'1'→49），完全不同于十六进制解析逻辑；
- & 0xFF 在输出中不可省略：String.format("%02X", b) 中若 b 为负数（如 -1），不加掩码会打印 FFFFFFF，b & 0xFF 强制取低 8 位，确保单字节无符号格式；
- 输入校验：确保 hex 字符串仅含 [0-9a-fA-F] 且长度为偶数，否则 parseInt 将抛出异常；
- Bouncy Castle 版本兼容性：上述代码适用于 BC 1.60+；若使用较新版本（如 1.70+），建议迁移到 org.bouncycastle.crypto.macs.CMac + org.bouncycastle.crypto.params.KeyParameter（当前示例已采用此标准路径）。
通过严格遵循十六进制字符串到字节数组的语义转换，即可彻底解决 Java/C# 双端 CMAC 签名不一致的问题，实现安全、可靠、可互操作的消息认证。
