x/crypto/openpgp: add cv25519 support

[keks]

While there is no official spec yet, GnuPG went ahead and implemented support for encrypting and signing OpenPGP messages using ed25518/curve25519. There is a draft spec for using ed25519 in OpenPGP can be found here and I heard it is likely to be merged in to the OpenPGP standard. At this point I am not sure whether there is a similar document for what has been implemented in GnuPG to encrypt messages using 25519.

I would like to extend the x/crypto/openpgp and x/crypto/openpgp/packet packages so they can sign, verify, decrypt and encrypt 25519 messages compatible to GnuPG. A subset of that would also be fine by me.

[dsnet]

\cc @agl

[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.

[benburkert]

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/

[keks]

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

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

[benburkert]

@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.

[keks]

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.

[benburkert]

@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.

[keks]

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?

[mjrider]

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