如何安全将C# SecureString转为UTF-8 byte[]并计算哈希？

首先得说，你当前的UTF-16实现已经做得很到位——固定数组、用完清零，这部分的安全意识拉满了。但问题确实出在Encoding.Convert这一步：这个方法会创建新的托管数组，哪怕你最后清零，中间GC的内存移动或者快照都可能留下敏感数据的痕迹，完全违背了SecureString的安全设计初衷。

下面直接给你最优解，既能跳过不必要的UTF-16托管数组步骤，又能保证全程敏感数据都在固定/非托管内存中操作，不会产生可被GC随意移动的副本：

核心思路 #

SecureString转出来的BSTR本身就是UTF-16的非托管内存块，我们可以直接从这个非托管内存块转换编码到固定的UTF-8托管数组，完全跳过把UTF-16拷贝到托管数组的步骤——这不仅提升了内存效率，还减少了敏感数据暴露的环节。

修改后的实现代码 #

public static byte[] Hash(this SecureString secureString, HashAlgorithm hashAlgorithm)
{
    IntPtr bstr = IntPtr.Zero;
    GCHandle utf8Pin = default;
    byte[] utf8Bytes = null;
    try
    {
        // 获取SecureString的非托管BSTR（UTF-16格式）
        bstr = Marshal.SecureStringToBSTR(secureString);
        // BSTR前4字节是总字节数，字符数=总字节数/2（因为UTF-16每个字符占2字节）
        int charCount = Marshal.ReadInt32(bstr, -4) / 2;
        // 获取UTF-16字符的直接指针
        IntPtr charPtr = bstr;

        // 计算转换为UTF-8需要的字节数
        int utf8Length = Encoding.UTF8.GetByteCount((char*)charPtr, charCount);
        // 分配UTF-8字节数组并固定，防止GC移动内存
        utf8Bytes = new byte[utf8Length];
        utf8Pin = GCHandle.Alloc(utf8Bytes, GCHandleType.Pinned);
        IntPtr utf8Ptr = utf8Pin.AddrOfPinnedObject();

        // 直接从非托管UTF-16转换到固定的UTF-8内存块，无额外中间副本
        Encoding.UTF8.GetBytes((char*)charPtr, charCount, (byte*)utf8Ptr, utf8Length);

        // 计算哈希值
        return hashAlgorithm.ComputeHash(utf8Bytes);
    }
    finally
    {
        // 彻底清零并释放所有敏感内存
        if (bstr != IntPtr.Zero)
        {
            Marshal.ZeroFreeBSTR(bstr);
        }
        if (utf8Bytes != null)
        {
            Array.Clear(utf8Bytes, 0, utf8Bytes.Length);
        }
        if (utf8Pin.IsAllocated)
        {
            utf8Pin.Free();
        }
    }
}

关键细节说明 #

1. 跳过UTF-16托管数组：直接用BSTR的字符指针charPtr计算UTF-8长度和转换编码，避免了把敏感数据拷贝到托管堆的UTF-16数组中。
2. 固定UTF-8数组：用GCHandle固定后，GC不会移动该数组的内存位置，编码转换直接写入固定内存，无额外中间副本。
3. 彻底清理内存：无论是BSTR的非托管内存，还是固定的UTF-8数组，用完都立即清零并释放，最大程度降低数据泄露风险。

关于你之前的转换位置 #

原来的转换逻辑（先拷贝到UTF-16数组再转UTF-8）确实不合适：

• 多了一次托管内存拷贝，敏感数据在托管堆留下了痕迹；
• Encoding.Convert生成的UTF-8数组是普通托管数组，GC可能在你清零前就移动它，导致内存中残留旧数据的副本。

额外优化提示 #

如果场景允许，甚至可以直接把哈希计算的目标指向固定的UTF-8内存块（部分HashAlgorithm实现支持直接写入非托管内存），不过大部分.NET内置哈希算法还是需要传入byte[]，所以当前方案已经是最优选择了。

内容的提问来源于stack exchange，提问作者Callum Watkins