Go HKDF 派生密钥读不满指定长度怎么办

Go HKDF 派生密钥读不满指定长度时，先看导入路径，再看返回的 n 与 err。使用 golang.org/x/crypto/hkdf 的 Reader 接口，定长需求应采用 io.ReadFull，同时确保同一个 Reader 的累计输出没有超过 255 × HashLen。SHA-256 的上限是 8160 字节，不是 8160 位；超过剩余额度时，增加循环读取次数并不能解决。

Reader 接口官方文档：https://pkg.go.dev/golang.org/x/crypto/hkdf

标准库接口官方文档：https://pkg.go.dev/crypto/hkdf

先分清：你的 HKDF 是否真的提供 Read 方法

旧项目常见的 x/crypto/hkdf.New 和 Expand 返回 io.Reader。标准库 crypto/hkdf.Key 和 Expand 则接收目标长度，直接返回字节切片和错误。两者都围绕 HKDF，但不能把包名相同理解成调用方式相同。

定长切片接口让新代码更容易表达“需要多少字节”，Reader 接口则保留了连续消费的使用方式。是否调整调用方式，应由项目工具链和既有协议决定；这里不把接口变化当作必须升级的理由，也没有依据声称某种写法更热门。

把一次请求长度与累计可用长度分开

HashLen 指哈希摘要的字节数，不是哈希分组大小，也不是输入密钥的长度。对于 SHA-256，sha256.Size 为 32，因此一次扩展所允许的最大输出是 255*32=8160 字节。长度参数、切片长度与累计记录统一使用字节；下游要求 256 位密钥时，对应 32 字节，而不是 256 字节。

Reader 不是无限随机流。若同一个 SHA-256 HKDF Reader 已消费 8144 字节，还剩 16 字节，再请求 32 字节便超出剩余额度。当前 x/crypto 实现会先判断本次请求能否完整满足；不足时可以直接返回错误和零字节，而不是先给剩下的 16 字节。

一般的 io.Reader 契约允许短读，因此固定长度用 io.ReadFull 更清楚。但不要由此误判 HKDF 正常运行总会随机短读：直接使用当前 x/crypto HKDF Reader 且额度足够时，其实现会填满本次缓冲区。若外面还有限长读取器或自定义包装层，要把那一层的返回行为也纳入记录。

定长读取失败时，不返回缓冲区充当密钥

下面的封装先检查长度，再创建全新的派生 Reader，最后用 ReadFull 获取目标长度。正长度限制是这个业务封装的约定，不表示所有底层接口都必须拒绝零长度。样例只输出长度和失败标志，不输出 secret、派生密钥或任何中间材料。

package main

import (
    "crypto/rand"
    "crypto/sha256"
    "fmt"
    "io"

    xhkdf "golang.org/x/crypto/hkdf"
)

func deriveFixed(secret, salt, info []byte, length int) ([]byte, error) {
    // 本封装只接受正长度，并在分配前拒绝超出HKDF扩展上限的请求。
    maxLength := 255 * sha256.Size
    if length  maxLength {
        return nil, fmt.Errorf("派生长度必须在1到%d字节之间", maxLength)
    }
    r := xhkdf.New(sha256.New, secret, salt, info)
    out := make([]byte, length)
    n, err := io.ReadFull(r, out)
    if err != nil {
        // 不返回未填满的缓冲区，错误中只包含计数，不包含密钥。
        return nil, fmt.Errorf("派生读取%d/%d字节: %w", n, length, err)
    }
    return out, nil
}

func main() {
    // 随机输入仅用于本地演示，实际系统必须遵守既定协议的参数约定。
    secret := make([]byte, 32)
    salt := make([]byte, 32)
    if _, err := rand.Read(secret); err != nil {
        panic(err)
    }
    if _, err := rand.Read(salt); err != nil {
        panic(err)
    }
    info := []byte("local-demo/data-key/v1")
    key, err := deriveFixed(secret, salt, info, 32)
    if err != nil {
        panic(err)
    }
    fmt.Printf("定长派生字节数=%d\n", len(key)) // 不输出任何密钥内容。

    r := xhkdf.New(sha256.New, secret, salt, info)
    // 消费到只剩16字节，再请求32字节，展示累计额度不足的错误。
    prefix := make([]byte, 255*sha256.Size-16)
    if _, err := io.ReadFull(r, prefix); err != nil {
        panic(err)
    }
    next := make([]byte, 32)
    n, err := io.ReadFull(r, next)
    fmt.Printf("累计额度演示：读取=%d，请求=%d，失败=%t\n",
        n, len(next), err != nil)
    // prefix和next仅用于演示；失败的next不得作为密钥交给业务。
}

该示例需要项目已有与自身工具链兼容的 golang.org/x/crypto 依赖。第一部分预期取得 32 字节；第二部分故意消费到仅剩 16 字节，再请求 32 字节，预期失败。这里给出的是可自行运行的对照写法，不是实际执行记录。不要依赖某个错误字符串或假定超限一定返回 io.EOF。

若自己包装 Reader，保留实际 n 和原始错误，再向业务返回失败；不要用零填充、重复旧字节或忽略错误来凑足长度。缓冲区分配了 32 字节，并不意味着已经成功派生了 32 字节。

输入参数决定输出内容，不负责增加额度

secret 是输入密钥材料，salt 参与提取，info 用于绑定用途上下文。排查两端密钥不一致时，应比较参数的编码与来源约定，而不在日志中直接打印这些敏感材料。参数的任意改动可能让输出变化，但不会将 SHA-256 的单次扩展上限变大。

同一组输入重新创建 Reader，会从相同派生序列的起点开始；它并不是沿着旧 Reader 的位置继续。不能用“每次读不满就重建 Reader”的办法拼出更长密钥，也不能在相同参数下反复取开头 32 字节并认为得到多个不同用途的独立密钥。用途区分应服从既有协议的 info 约定，而不是排障时随意改值。

扩大输出不是创造新的输入熵。本文假设已有满足协议要求的密钥材料，不把普通口令直接当作高强度主密钥，也不讨论密码协议设计。若调用 Expand 跳过提取，其输入要求与完整派生不同；修复长度问题时不要顺手跳过提取步骤。

固定长度需求可采用标准库，但保留原有参数语义

项目工具链具备 crypto/hkdf 时，可以将固定长度需求封装为下面的形式。该版本不使用 Reader，也不需要 ReadFull。info 改成字符串参数后，要保留原来的字节序列，而不是额外做十六进制、Base64 或字符规范化处理。

package derivation

import (
    "crypto/hkdf"
    "crypto/sha256"
    "fmt"
)

func DataKey(secret, salt []byte, info string, length int) ([]byte, error) {
    // 正长度是本业务封装的规则；先拒绝超限再调用标准库。
    if length  255*sha256.Size {
        return nil, fmt.Errorf("不支持的派生长度：%d字节", length)
    }
    key, err := hkdf.Key(sha256.New, secret, salt, info, length)
    if err != nil {
        return nil, fmt.Errorf("HKDF派生失败: %w", err)
    }
    return key, nil
}

迁移还需确认原来的调用是在同一 Reader 上连续分段读取，还是每个用途独立派生。将连续分段读取机械改成相同参数的多次 Key 调用，会改变结果分配方式：多次调用不会自动记住上一次消费的位置。保持协议定义的参数与切分规则，比简单替换 import 更重要。

定位时记录导入路径、哈希名、请求字节数、同一 Reader 已消费量、返回字节数和错误即可。标准库返回的其他错误也要向上传递，不能把所有失败都当作长度超限。成功条件是错误为空且结果达到约定长度；长度满足本身并不证明整套密钥使用方案正确。

salt 为 nil 会让结果变短吗？

HKDF 支持省略 salt，这不是增加输出额度或处理短读的开关。是否允许省略由协议约定决定，不要为消除错误而临时换盐。

能否读取到 EOF，再判断拿到多少？

定长密钥不应依赖“读到结束”。直接请求协议需要的字节数并处理错误，避免用 ReadAll 把有限派生器当普通文件读取。

刚好需要超过 8160 字节怎么办？

先排除位与字节混淆、把文本编码长度误当密钥长度，以及重复消费的计数错误。确实超出时，应重新核对协议设计，不能通过循环读取或重复起点输出来绕过 HKDF 的长度限制。

长度与参数规范：https://www.rfc-editor.org/rfc/rfc5869.html