SPDK项目中NVMe DH-HMAC-CHAP认证的公钥长度问题解析

问题背景

在SPDK存储性能开发工具包中，NVMe over Fabrics协议的DH-HMAC-CHAP认证机制实现存在一个关键的技术问题。该问题涉及在密钥交换过程中生成的Diffie-Hellman公钥长度不符合NVMe规范要求。

技术细节

NVMe规范明确要求DH-HMAC-CHAP认证过程中传输的Diffie-Hellman公钥长度(DHVLEN字段)必须是4的倍数。然而在实际测试中发现，SPDK的spdk_nvme_dhchap_dhkey_get_pubkey函数在某些情况下会返回不符合此要求的长度值，如1023字节而非预期的1024字节，或511字节而非512字节。

根本原因分析

经过深入调查，发现问题根源在于使用了OpenSSL库的BN_num_bytes函数来获取密钥长度。该函数有一个重要特性：它不会计算数值中不显著的高位零比特，因此返回的长度可能比实际密钥位数对应的字节数少1。例如，一个1024位的密钥理论上需要128字节存储，但如果最高位字节为零，BN_num_bytes将返回127字节。

解决方案

正确的做法是使用OpenSSL的EVP_PKEY_get_size函数替代BN_num_bytes。EVP_PKEY_get_size会返回密钥的实际大小(以字节为单位)，这个值总是与密钥位数对应的完整字节数，确保符合NVMe规范中对长度必须是4的倍数的要求。

影响与验证

这个问题在反复运行认证测试脚本时会被发现，特别是在修改了内核NVMe目标端(nvmet)驱动程序添加了长度验证逻辑后。当内核检测到不符合规范的长度值时，会中止认证过程，导致测试失败。

技术意义

这个修复确保了SPDK实现的NVMe over Fabrics认证机制完全符合协议规范，提高了与其他实现(如Linux内核NVMe驱动)的互操作性。同时，它也展示了在使用密码学库时需要注意的细节问题——不同的长度计算函数可能有不同的行为特性，选择正确的API对于协议合规性至关重要。

总结

在存储系统开发中，协议规范的严格遵守是确保系统稳定性和互操作性的基础。SPDK团队通过这个问题修复，不仅解决了具体的技术问题，也为开发者提供了一个有价值的经验：在使用密码学原语时，必须仔细理解所用API的精确行为，特别是在处理长度和边界条件时。