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

Add support for generating ed25519 keys and certificates #1097

Closed
wants to merge 20 commits into from

Conversation

claucece
Copy link
Contributor

This PR is WIP, and it is built upon: #1061 by @izolight .

@lgarofalo , I will be putting the new commits over here, so let me know if it is ok ;)

@claucece
Copy link
Contributor Author

One of the things that this does is remove the go 1.12 as the built target, as the ed25519 package is part of std library...

@armfazh
Copy link

armfazh commented Apr 20, 2020

Have you considered to use CIRCL for ed signatures?

@claucece
Copy link
Contributor Author

Oh, neat idea @armfazh ! I'll start playing with that ;)

@claucece
Copy link
Contributor Author

On the same note @armfazh .. I think openssl also supports ed448, so maybe we can support here as well with your implementation?

@claucece
Copy link
Contributor Author

So, several tests are missing and some needs to be checked for the ed algorithm:

  • TestBundleWithECDSAKeyMarshalJSON
  • TestGenerate
  • TestUbiquitousBundle
  • TestUbiquityBundleWithoutMetadata
  • TestForceBundleNoFallback
  • TestSHA2HomogeneityAgainstUbiquity

@armfazh
Copy link

armfazh commented Apr 22, 2020

I think openssl also supports ed448, so maybe we can support here as well with your implementation?

That is a great idea, let me know if the current CIRCL API needs changes. Happy to review concise PRs.

@claucece
Copy link
Contributor Author

For sure! I'll finish this PR, and then create another one for ed448 @armfazh . Thanks so much!

@claucece
Copy link
Contributor Author

I jumped into some interfaces conversion problems with using circl, as detailed on issue: cloudflare/circl#109 . Let's see if that can be modified and if not, I'll try something else ;)

@claucece
Copy link
Contributor Author

This also should be taken into account: golang/go#20544

@claucece
Copy link
Contributor Author

So, @armfazh , I've been playing with different ideas but it does not seem like it will work with CIRCL: the 'CreateCertificate' from the X509 package only supports "The currently supported key types are *rsa.PublicKey, *ecdsa.PublicKey and ed25519.PublicKey" (https://golang.org/pkg/crypto/x509/#CreateCertificate), which forces to use the ed25519 from Golang, or do a "conversion" of some kind (which still will mean that package 25519 is needed, ruling out go 1.12). I'll finish this PR by switching back to Golang's ed25119; but I could maybe start an issue into Golang x/crypto libraries for support of ed448 (now that some applications like Privacy Pass will actually need it) and adding it to x509.

cc./ @alxdavids

@armfazh
Copy link

armfazh commented Apr 30, 2020

One can use circl for signature operations, while being compliant with stdlib types.
Take a look on claucece#1

@claucece
Copy link
Contributor Author

claucece commented May 1, 2020

Yes! @armfazh , just did the same! ;) It is sad that we will probably only be able to signing (with ed448, as well).. but well. I'll try to see if in the actual Golang libraries, ed448 can be implemented. I found this issue that mentions that it will be good to have ed448: https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+ed448

@claucece
Copy link
Contributor Author

So, @lgarofalo , as part of this PR, I realized that some of the data used for testing is expired, which shouldn't matter while testing as if not we will have to change the data every time that it gets expired. I added a small fix on the previous commit. Let me know if you think is ok ;)

@codecov-commenter
Copy link

codecov-commenter commented May 22, 2020

Codecov Report

Merging #1097 into master will increase coverage by 0.19%.
The diff coverage is 50.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1097      +/-   ##
==========================================
+ Coverage   56.27%   56.47%   +0.19%     
==========================================
  Files          77       76       -1     
  Lines        7309     7354      +45     
==========================================
+ Hits         4113     4153      +40     
+ Misses       2727     2723       -4     
- Partials      469      478       +9     
Impacted Files Coverage Δ
bundler/bundle.go 80.23% <0.00%> (-4.96%) ⬇️
bundler/bundler.go 77.97% <0.00%> (-1.25%) ⬇️
helpers/derhelpers/ed25519.go 53.84% <ø> (ø)
signer/signer.go 22.81% <0.00%> (-0.23%) ⬇️
initca/initca.go 60.86% <42.85%> (-0.97%) ⬇️
transport/kp/key_provider.go 40.33% <45.00%> (+6.38%) ⬆️
helpers/helpers.go 73.21% <75.00%> (+0.04%) ⬆️
csr/csr.go 84.83% <86.36%> (-0.26%) ⬇️
helpers/derhelpers/derhelpers-legacy.go

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6b49bea...21fb139. Read the comment docs.

@claucece
Copy link
Contributor Author

@armfazh .. maybe you can help me on this (this current PR has lots of debugging, sorry for that): for some reason using the circl ed25519 fails on the s390x machines, and not on the 64 archs. Using the stdlib ed21559 works just fine. Any ideas?

@armfazh
Copy link

armfazh commented May 22, 2020

Let's do baby steps first, so we can make small incremental changes.
This PR is for integrating eddsa into cfssl (use stdlib first).
In another PR, we can make changes to replace stdlib with CIRCL.

In the meantime, we can check what makes circl to fail on s390x architecture.

@claucece
Copy link
Contributor Author

Perfect @armfazh !

Then, I will:

  • close the PR with stdlib
  • make a PR/issue to track what is happening with eddsa in CIRCL at s390x
  • integrate eddsa with CIRCL here

Thanks so much!

@claucece
Copy link
Contributor Author

Ok, this PR is basically done.

There is a small thing I found out: the tls package inside the scan folder, that is vendored, has not been update from stdlib in a while. Not sure if it is the best thing to do right now, but the latest version adds there the support for ed25519.

@armfazh @lgarofalo

@lukevalenta
Copy link
Contributor

There is a small thing I found out: the tls package inside the scan folder, that is vendored, has not been update from stdlib in a while. Not sure if it is the best thing to do right now, but the latest version adds there the support for ed25519.

This should be addressed with #1101 (still a WIP).

@cbroglie cbroglie removed their request for review May 27, 2020 17:14
@claucece
Copy link
Contributor Author

Awesome @ltv511 ! I'll keep and eye on it and wait until that one is merged ;)

csr/csr.go Outdated
case ed25519.PrivateKey:
key, err = derhelpers.MarshalEd25519PrivateKey(priv)
if err != nil {

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a line missing here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, yes! I'll add it ;) Thanks for pointing it out!

@armfazh
Copy link

armfazh commented Jul 16, 2020

A small comment: run go mod tidy to remove the unused dependencies and update vendor folder.

@claucece
Copy link
Contributor Author

Just did it @armfazh . I started a conversation on #1101 to see if I can chime in there. If there is no answer till Friday, I'll start doing it ;)

default:
panic("Generate should have failed to produce a valid key.")
}

csr, err = Generate(priv.(crypto.Signer), req)
csr, err = Generate(priv.(crypto.Signer), req) // TODO: solve
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the problem the todo refers to?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, this was a remanent of thinking how to change some x509 things..

@@ -241,9 +244,30 @@ func (sp *StandardProvider) Generate(algo string, size int) (err error) {
}
sp.internal.keyPEM = pem.EncodeToMemory(p)

sp.internal.priv = priv
case "ed25519":
if size != (ed25519.PublicKeySize * 8) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The size parameter doesn't refer to the actual size of the public key, does it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, yes.. this should probably refer to the private key size. I'll change this.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is counterintuitively right. ed25519.PrivateKeySize accounts for both the public key (32 bytes) and the seed (32 bytes), totaling 64 bytes. ed25519.go

However, I do not see the point of specifying the key size, since ed25519 is always the same, as I know. I think the field size should be simply ignored when generating ed25519 keys.

@centromere
Copy link

Thank you for working on this. Is it ready to go?

@lukevalenta
Copy link
Contributor

Thank you for working on this. Is it ready to go?

Looks like it's not quite ready to go. @claucece is no longer at Cloudflare, so we may need someone else to champion this PR.

@johannww
Copy link

johannww commented Nov 30, 2022

I stumbled into this trying to support ed25519 in fabric-ca. I merged the current master branch with this pull request's branch https://github.com/johannww/cfssl. Everything compiles. The only test failing is the one on github.com/cloudflare/cfssl/bundler, but it is also failing in the current master branch. I generated an ed25519 key successfully.

It seems to work. I will leave some comments in the commit.

izolight added a commit to izolight/cfssl that referenced this pull request May 26, 2023
@izolight
Copy link
Contributor

I merged this PRs changes and master into my original PR #1061
I've also addressed the last two open points on this MR in it.

@nickysemenza
Copy link
Member

closing in favor of #1061

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

Successfully merging this pull request may close these issues.

9 participants