C# 的 Rfc2898DeriveBytes 默认使用 UTF-16 编码处理密码和盐值，而 Go 原生字符串为 UTF-8 编码，导致字节序列不同，进而使 PBKDF2 输出不一致；本文详解差异成因，并提供可复现、跨语言对齐的 Go 实现。
c# 的 `rfc2898derivebytes` 默认使用 utf-16 编码处理密码和盐值，而 go 原生字符串为 utf-8 编码，导致字节序列不同，进而使 pbkdf2 输出不一致；本文详解差异成因，并提供可复现、跨语言对齐的 go 实现。
在密码学实践中，跨语言实现 PBKDF2（如 .NET 的 Rfc2898DeriveBytes 与 Go 的 pbkdf2.Key）时，若未严格对齐输入字节表示，极易出现哈希结果不一致的问题——这并非算法差异，而是编码层的隐式约定冲突。
核心差异在于字符串到字节的转换方式：
-
C#
Encoding.Unicode对应 UTF-16LE（小端序），每个字符至少占 2 字节。例如"47687"→[52,0,55,0,54,0,56,0,55,0]（10 字节）； -
Go
[]byte("47687")默认为 UTF-8，ASCII 字符单字节，结果为[52,55,54,56,55]（5 字节）。
因此，即使迭代次数、哈希函数（SHA-1）、密钥长度（32 字节）完全相同，输入盐和口令的字节流不同，PBKDF2 输出必然不同。
✅ 正确做法：在 Go 中模拟 .NET 的 UTF-16LE 编码逻辑。以下为完整、可验证的对齐实现：
package main
import (
"crypto/sha1"
"encoding/binary"
"encoding/base64"
"fmt"
"golang.org/x/crypto/pbkdf2"
"unicode/utf16"
)
var (
PasswordSecuritySalt = "47687"
PasswordSecurityIterations = 1000
PasswordSecurityKeylen = 32
)
// stringToUTF16Bytes 将字符串按 UTF-16LE 编码为字节切片（等效于 C# Encoding.Unicode.GetBytes）
func stringToUTF16Bytes(s string) []byte {
runes := utf16.Encode([]rune(s))
bytes := make([]byte, len(runes)*2)
for i, r := range runes {
binary.LittleEndian.PutUint16(bytes[i*2:], r) // 小端序写入
}
return bytes
}
func HashPassword(str string) string {
key := pbkdf2.Key(
stringToUTF16Bytes(str), // 口令 UTF-16LE 编码
stringToUTF16Bytes(PasswordSecuritySalt), // 盐 UTF-16LE 编码
PasswordSecurityIterations,
PasswordSecurityKeylen,
sha1.New,
)
return base64.StdEncoding.EncodeToString(key)
}
func main() {
result := HashPassword("123456")
fmt.Println(result) // 输出：aOyDnGG22ebqGmMvY7zQwdT+UKF6hUUmAt2Uc0jj2io=
}
? 关键注意事项：
- 必须使用
golang.org/x/crypto/pbkdf2（非标准库crypto/pbkdf2，后者不支持自定义哈希构造函数）； -
utf16.Encode处理 Unicode 码点，对 ASCII 字符也生成双字节（含零填充），严格匹配Encoding.Unicode行为； - 若盐或口令含非 ASCII 字符（如中文），该方案仍能正确对齐，因 UTF-16 编码逻辑一致；
- 生产环境建议避免依赖字符串编码隐式行为：显式约定并持久化盐的原始字节（如 Base64 存储），而非字符串字面量。
通过统一输入字节表示，Go 与 C# 的 PBKDF2 结果即可完全一致——这是跨平台密码派生可靠性的基础前提。
