Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/crypto/openpgp: add cv25519 support #18576

Closed
keks opened this issue Jan 9, 2017 · 12 comments
Closed

x/crypto/openpgp: add cv25519 support #18576

keks opened this issue Jan 9, 2017 · 12 comments

Comments

@keks
Copy link

@keks keks commented Jan 9, 2017

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 dsnet added this to the Unreleased milestone Jan 9, 2017
@dsnet
Copy link
Member

@dsnet dsnet commented Jan 9, 2017

\cc @agl

@agl
Copy link
Contributor

@agl agl commented Jan 9, 2017

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.

@rsc rsc changed the title proposal: Add cv25519 support to x/crypto/openpgp x/crypto/openpgp: add cv25519 support Jan 9, 2017
@benburkert
Copy link
Contributor

@benburkert benburkert commented Jan 11, 2017

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
Copy link
Author

@keks keks commented Jan 11, 2017

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
Copy link
Contributor

@benburkert benburkert commented Jan 12, 2017

@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
Copy link
Author

@keks keks commented Jan 12, 2017

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
Copy link
Contributor

@benburkert benburkert commented Jan 13, 2017

@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
Copy link
Author

@keks keks commented Jan 19, 2017

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
Copy link

@mjrider mjrider commented Apr 24, 2018

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

@aviau
Copy link

@aviau aviau commented May 22, 2018

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.

@keks
Copy link
Author

@keks keks commented May 22, 2018

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.

@FiloSottile
Copy link
Contributor

@FiloSottile FiloSottile commented Mar 29, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants