My reason for hand-rolling it was wrong

说明与用途

作者将自定义 OpenPGP 实现替换为 ProtonMail/go-crypto，发现该库支持 KMS‑based 签名，但缺乏 ECDH 解密接口，并且增加了依赖项和 CVE 数量。

问题

The author needed to use OpenPGP in Go with a key stored in a KMS that cannot expose private key material, but the maintained library ProtonMail/go-crypto seemed unable to support this.

结果

Replacing the hand‑rolled code with go-crypto eliminated the need for custom packet logic, but exposed gaps in ECDH support and increased the dependency footprint with associated CVEs.

工作流

• 1. Deleted the 400‑line hand‑rolled package.
• 2. Replaced it with ProtonMail/go-crypto in go.mod.
• 3. Ran acceptance tests to verify functionality.
• 4. Observed that packet.PrivateKey accepts a crypto.Signer, enabling KMS signing.
• 5. Noted that ECDH decryption still requires a concrete *ecdh.PrivateKey and lacks a crypto.Decrypter interface.
• 6. Compared dependency footprints and CVE counts before and after.
• 7. Reviewed open PRs and issues for ECDH support.
• 8. Updated tests to compare session keys between go-crypto and gpg.

证据

I deleted the package. Actually removed it (not "decided not to use it", gone), wired go-crypto in its place, and ran the acceptance tests to see what broke.

来源

packet.PrivateKey accepts a crypto.Signer in place of an actual key, so a signature can be made by something that never exposes any key material, which is more or less the definition of a KMS.

来源

go-crypto's encrypted_key.go hard-asserts *ecdh.PrivateKey when it decrypts a PKESK packet, so there is no interface to implement, no crypto.Decrypter equivalent for ECDH, and no way to hand it a shared secret computed somewhere else.

来源

Pulling go-crypto in costs golang.org/x/crypto, github.com/cloudflare/circl and everything underneath them, and when that dependency went in during the experiment it brought eighteen CVEs along that had to be resolved by raising pins.

来源