libtomcrypt项目中SSH RSA密钥解密在64位大端架构上的修复方案

在密码学库libtomcrypt的近期开发中，开发团队发现了一个影响特定硬件架构的SSH RSA密钥解密问题。该问题主要出现在64位大端字节序（big-endian）的处理器架构上，包括但不限于s390x、ppc64、sparc64和x32等平台。

问题背景

SSH协议中使用的RSA密钥在加密存储时，通常会采用特定的密钥派生函数（KDF）进行保护。在libtomcrypt的实现中，当使用"bcrypt"作为KDF时，代码需要处理盐值（salt）和轮次（rounds）等参数。原始实现中存在一个潜在的类型转换问题，可能导致在大端架构上解析密钥时出现异常。

技术分析

问题的核心在于pem_ssh.c文件中的s_decode_header函数实现。该函数负责解析SSH密钥的头部信息，特别是处理bcrypt KDF的相关参数：

1. 原始代码直接将sizeof(opts->salt)的结果赋值给opts->saltlen，这是一个ulong32类型（32位无符号整数）
2. 随后在调用ssh_decode_sequence_multi时，将opts->saltlen的地址传递给参数，该参数期望的是unsigned long*类型（64位系统上通常是64位无符号整数）
3. 这种类型不匹配在大端架构上会导致盐值长度解析错误

解决方案

修复方案引入了中间变量saltlen作为unsigned long类型，确保与ssh_decode_sequence_multi函数的参数类型匹配。具体修改包括：

1. 使用临时变量saltlen存储盐值长度
2. 在调用解码函数时使用这个临时变量
3. 添加长度验证，防止可能的整数溢出
4. 最后将验证后的值安全地转换为ulong32类型

这种修改既保持了与原有32位系统的兼容性，又解决了64位大端架构上的类型转换问题，同时增加了安全性检查。

影响范围

该修复主要影响以下场景：

• 使用bcrypt作为KDF的SSH RSA密钥解密
• 运行在64位大端架构上的系统
• 涉及密钥导入/解密操作的功能

对于大多数x86_64等小端架构系统，此问题不会显现，但修复后的代码在这些平台上同样能更安全地运行。

总结

这次修复展示了在密码学库开发中处理跨平台兼容性问题的重要性，特别是在类型系统和字节序方面的细致考虑。通过引入中间变量和显式类型检查，不仅解决了特定架构上的问题，还增强了代码的健壮性。对于开发者而言，这也提醒我们在处理加密数据时，必须特别注意数据类型在不同平台上的表现差异。