当前位置：首页 > 文章列表 > Golang > Go教程 > Go crypto/hpke 怎样组织一次混合公钥加密

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

来源：17golang原创 2026-10-18 04:58:24 0浏览收藏

如果你的目标是让发送方只拿到接收方公钥，却能把一段消息交给接收方解密，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，后两者分别负责密钥派生和认证加密。实际项目要根据双方支持范围固定套件，不要在协议两端各自“挑一个看起来更安全的选项”。

HPKE 的 KEM、KDF、AEAD 三层静态结构说明图 — 图1：KEM、KDF、AEAD 三层如何组成 HPKE 套件；这是静态结构说明图，不是截图或运行证据。

先生成接收方密钥

接收方负责生成密钥对，并把 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 不加密，但接收方必须传入完全相同的内容。

HPKE 发送方封装信息与接收方解封装数据关系图 — 图2：公钥、封装信息、认证密文和私钥之间的静态关系；这是结构说明图，不是运行结果截图。

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

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

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