\cc @agl

No objections here if a) resulting patch is good, b) it interoperates with GnuPG and c) GnuPG have indicated that they don't intend to change the format somehow.

This patch set adds ECDH and EdDSA support: benburkert/crypto@7c6cc32...f082785

The first CL in the series is here: https://go-review.googlesource.com/#/c/22095/

Great to see I don't have to do all the work ;)

The way I see it all is done except curve25519 ecdh, right?

@keks yep, and as far as I know cv25519 doesn't appear in any RFC, draft or otherwise. It seems to exist only in libgcrypt.

Related: There is a proposed update on the rfc 4880bis draft spec: https://mailarchive.ietf.org/arch/msg/openpgp/ssRMnXUapc6u_mNyRQ6aLlYXthA

Seems like this was an error...Two days ago I discovered that in the draft the actual EdDSA private key k is not supposed to be stored, only the secret scalar (the left hand side of SHA2-512(k)). However, k key is needed to compute signatures (at least for deterministic signatures - I suspect one could also use a random value).

Technical question: Should I "resume" your CL? Can I fork it? How would I go about this? This is my first contribution to the Go project and I didn't expect that someone else already worked on this. I only searched for ed25519, not EdDSA in Gerrit.

Since the spec has shown to be incomplete, I suggest using the GnuPG implementation as authoritative. The code has been out for a while and there already are quite a lot of people using the new keys, so even if the standard will be different, it is unlikely that they will reuse the protocol IDs used in GnuPG.

@keks I just resubmitted CL22095, please have a look. The EdDSA change doesn't rely on any of the other ECDH work, so I'll submit both the ECDH & EdDSA changes in parallel next. I expect the ECDH CLs will take some time to get the keywrap stuff properly attributed. But you could start working on Curve25519 support on top of the patch set.

I agree with following the GnuPG implementation. The EdDSA change was adapted from a separate fork of x/crypto/openpgp. That repo has some test harnesses for shelling out to gpg2 which could come in handy while implementing Curve25519.

Sorry for not responding. I'm still on this just kind of busy atm. I will take another look next week.

Should I reuse your Changi-Id or should I create a new change?

@keks @benburkert what should be done to get this moving again ?

I'd love to see this going!

ed25519 has gained adotion. A good number (or all) of the strong keys in the web of trust have at least have one ed25519 signature on them. This makes it impossible to use the openpgp package to create keyrings with those keys.

Unfortunately I currently don't have time I can invest in this effort. When I looked at this, there was no reliable documentation on what GnuPG actually does to do cv25519 and ed25519. There is the draft of RFC4880bis, but back when I looked at it, the parts on these algorithms were at best lacking information and at worst wrong.
Since the time I worked on this, some GnuPG devs moved to NeoPG and the Rust implementation Sequoia, maybe once they implement djb curves we have something more readable to look at than libgcrypt. Let's hope for the best.

Per the accepted #44226 proposal and due to lack of maintenance, the golang.org/x/crypto/openpgp package is now frozen and deprecated. No new changes will be accepted except for security fixes. The package will not be removed.

If this is a security issue, please email security@golang.org and we will assess it and provide a fix.

If you're looking for alternatives, consider the crypto/ed25519 package for simple signatures, golang.org/x/mod/sumdb/note for inline signatures, or filippo.io/age for encryption. You can read a summary of OpenPGP issues and alternatives here.

If you are required to interoperate with OpenPGP systems and need a maintained package, we suggest considering one of multiple community forks of golang.org/x/crypto/openpgp. We don't endorse any specific one.