Go crypto/hpke 怎样组织一次混合公钥加密

如果你的目标是让发送方只拿到接收方公钥，却能把一段消息交给接收方解密，Go 1.26 的 crypto/hpke 可以直接完成这件事。最小闭环是：接收方用 KEM 生成密钥对，发送方用公钥调用 hpke.Seal，接收方再用私钥调用 hpke.Open。返回的密文已经把封装信息和实际密文放在一起，不需要自己设计拼包格式。

官方地址：https://pkg.go.dev/crypto/hpke

我在阅读这个包时，最容易混淆的是“混合”并不等于把几个算法随意串起来。HPKE 的套件由 KEM、KDF、AEAD 三层组成，双方必须使用相同的组合；公钥可以分发，私钥只在接收方保存。

先把 KEM、KDF 和 AEAD 分开

KEM 负责从接收方公钥和发送方的临时材料中得到共享秘密，并产生封装信息；KDF 负责把共享秘密派生成会话所需的密钥；AEAD 负责认证加密正文。Go 包把三层分别表示成 KEM、KDF、AEAD，因此代码中的选择是明确的，而不是藏在一个模糊的“加密配置”里。

例如可以先选 MLKEM768X25519()、HKDFSHA256() 和 AES256GCM()。前者是后量子混合 KEM，后两者分别负责密钥派生和认证加密。实际项目要根据双方支持范围固定套件，不要在协议两端各自“挑一个看起来更安全的选项”。

先生成接收方密钥

接收方负责生成密钥对，并把 PublicKey() 交给发送方。这里的公钥对象不是一段可以随意改写的业务字符串；如果需要跨进程或跨语言传输，应按对应 KEM 的序列化规则保存和恢复，私钥则进入专门的密钥管理边界。

package main

import "crypto/hpke"

func receiverKey() (hpke.PrivateKey, hpke.PublicKey, error) {
	// 选择一个双方都支持的 KEM；它决定封装和解封装的密钥类型。
	kem := hpke.MLKEM768X25519()
	privateKey, err := kem.GenerateKey()
	if err != nil {
		return nil, nil, err
	}
	// 公钥可以交给发送方，私钥只留在接收方。
	return privateKey, privateKey.PublicKey(), nil
}

用 Seal 和 Open 完成一次闭环

单条消息最适合先用一站式 API。发送方拿到公钥后，以同样的 KDF、AEAD 和 info 调用 Seal；接收方使用同一套参数和私钥调用 Open。info 是双方都知道的公开上下文，它必须完全一致，否则派生出的上下文不同，解密会失败。

package main

import (
	"crypto/hpke"
	"fmt"
)

func roundTrip(publicKey hpke.PublicKey, privateKey hpke.PrivateKey) error {
	// 三层算法必须在发送方和接收方保持一致。
	kdf := hpke.HKDFSHA256()
	aead := hpke.AES256GCM()
	info := []byte("orders:v1") // 公开协议上下文，双方必须完全相同
	plaintext := []byte("order-123")

	// Seal 返回“封装信息 + 认证密文”的组合数据。
	ciphertext, err := hpke.Seal(publicKey, kdf, aead, info, plaintext)
	if err != nil {
		return err
	}
	// Open 按同一套 KEM 私钥、KDF、AEAD 和 info 恢复明文。
	decoded, err := hpke.Open(privateKey, kdf, aead, info, ciphertext)
	if err != nil {
		return err
	}
	fmt.Println(string(decoded))
	return nil
}

这个示例没有手动传 AAD；如果业务需要把订单号、协议版本等公开字段绑定进认证范围，应使用 NewSender 与 NewRecipient，再调用它们的 Seal(aad, plaintext) 和 Open(aad, ciphertext)。AAD 不加密，但接收方必须传入完全相同的内容。

多条消息要换成有状态上下文

Sender 和 Recipient 会维护递增计数器。发送方通过 NewSender 得到 enc 与上下文，接收方用同一个 enc 调用 NewRecipient；此后每次 Seal 与 Open 要保持相同顺序。不要把同一个上下文分给多个没有顺序协调的并发写入者，也不要把一次性密文拆成另一套自定义格式。

如果只需要导出共享秘密而不直接做 AEAD，可以选择 ExportOnly()，但此时 Seal 和 Open 本来就会返回错误。它不是“加密失败”，而是这个 AEAD 占位实现的设计边界。

上线前检查四个边界

• 固定 KEM、KDF、AEAD 和 info 的协议版本，不要依赖两端默认值。
• 私钥只在接收方密钥边界内使用；公钥、封装信息和密文可以进入消息传输。
• 跨语言互操作时，先确认 RFC 9180 的序列化和套件标识，不能只对照函数名。
• HPKE 只解决公钥加密上下文，不自动提供身份认证、密钥轮换、撤销和审计。

简单记忆就是：KEM 负责“怎样得到共享秘密”，KDF 负责“怎样派生会话密钥”，AEAD 负责“怎样认证加密数据”；Seal/Open 适合先打通单条消息，Sender/Recipient 适合明确管理消息顺序的连续会话。

相关问题

HPKE 的 info 能不能为空？

可以，但如果协议有版本、用途或租户边界，最好把这些公开上下文纳入 info，并在两端统一。

封装信息需要保密吗？

不需要。它要和密文一起送到接收方，私钥才是必须保护的秘密。

为什么同一 Sender 不能随意并发调用？

因为上下文维护递增计数器，接收方的 Open 也必须按发送方 Seal 的成功顺序处理。