Skip to content

Support for 25519 algos #4556

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

Open
wants to merge 25 commits into
base: master
Choose a base branch
from

Conversation

McMastS
Copy link
Contributor

@McMastS McMastS commented Feb 18, 2025

What?

Adds support for Ed25519 and X25519 algorithms in K6's webcrypto offering.

This PR is still in draft, and I will add the following as I have time:

  • Ed25519 key generation
  • Ed25519 signing
  • Ed25519 verifying
  • Ed25519 export
  • Ed25519 import
  • X25519 key generation
  • X25519 derive bits
  • X25519 import
  • X25519 export
  • See if I can help look into why the Webcrypto tests don't fail properly
  • Example scripts

Why?

Checklist

  • I have performed a self-review of my code.
  • I have added tests for my changes.
  • I have run linter locally (make lint) and all checks pass.
  • I have run tests locally (make tests) and all tests pass.
  • I have commented on my code, particularly in hard-to-understand areas.

Related PR(s)/Issue(s)

Closes #4263

@McMastS McMastS marked this pull request as ready for review April 7, 2025 22:54
@McMastS McMastS requested a review from a team as a code owner April 7, 2025 22:54
@McMastS McMastS requested review from inancgumus and joanlopez and removed request for a team April 7, 2025 22:54
@McMastS
Copy link
Contributor Author

McMastS commented Apr 7, 2025

Two minor TODOs are left, but the bulk of the PR is ready for review. Sorry for the big one!

I'm also looking into why the WebCrypto platform tests aren't running properly (see #4555 )

Copy link
Member

@inancgumus inancgumus left a comment

Choose a reason for hiding this comment

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

Thanks for your contribution 🙇 I have some suggestions and questions.

Comment on lines +696 to +699
if normalizeAlgorithmName == ECDH {
if err := ensureKeysUseSameCurve(privateKey, publicKey); err != nil {
return NewError(InvalidAccessError, err.Error())
}
Copy link
Member

Choose a reason for hiding this comment

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

What's the reason for using ensureKeysUseSameCurve only for ECDH? How does this change the previous behavior?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Previously, we only had ECDH algorithms going through the DeriveKey, which need that ensureKeysUseSameCurve function, but the X25519 keys always use the X25519 curve. Inside ensureKeysUseSameCurve we assert that the Algorithm types attached to the keys are both EcKeyAlgorithm but X25519 keys use the base Algorithm type.

Would a comment be helpful here to explain the new path?

Copy link
Member

Choose a reason for hiding this comment

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

Yes, a comment would be helpful 🙇

+ // {name: "Ed25519", resultType: "CryptoKeyPair", usages: ["sign", "verify"], mandatoryUsages: ["sign"]},
+ // {name: "Ed448", resultType: "CryptoKeyPair", usages: ["sign", "verify"], mandatoryUsages: ["sign"]},
+ // {name: "X25519", resultType: "CryptoKeyPair", usages: ["deriveKey", "deriveBits"], mandatoryUsages: ["deriveKey", "deriveBits"]},
{name: "X25519", resultType: "CryptoKeyPair", usages: ["deriveKey", "deriveBits"], mandatoryUsages: ["deriveKey", "deriveBits"]},
- {name: "X448", resultType: "CryptoKeyPair", usages: ["deriveKey", "deriveBits"], mandatoryUsages: ["deriveKey", "deriveBits"]},
+ // {name: "X448", resultType: "CryptoKeyPair", usages: ["deriveKey", "deriveBits"], mandatoryUsages: ["deriveKey", "deriveBits"]},
Copy link
Member

Choose a reason for hiding this comment

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

Since we implemented Ed25519 and X448, we can remove the commented-out lines.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ed25519 and X25519 are uncommented in here (I had to read this in the split diff view, it's very hard to read otherwise). Is X448 implemented? I didn't implement it in this PR.

Copy link
Member

@inancgumus inancgumus Apr 17, 2025

Choose a reason for hiding this comment

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

Sorry, I mean X25519, not X448. Ed25519 and X25519 are commented in the diff I see.

Comment on lines -21 to 23
+ // {name: "Ed25519", resultType: "CryptoKeyPair", usages: ["sign", "verify"], mandatoryUsages: ["sign"]},
+ {name: "Ed25519", resultType: "CryptoKeyPair", usages: ["sign", "verify"], mandatoryUsages: ["sign", "wrapKey"]},
+ // {name: "Ed448", resultType: "CryptoKeyPair", usages: ["sign", "verify"], mandatoryUsages: ["sign"]},
+ // {name: "X25519", resultType: "CryptoKeyPair", usages: ["deriveKey", "deriveBits"], mandatoryUsages: ["deriveKey", "deriveBits"]},
{name: "X25519", resultType: "CryptoKeyPair", usages: ["deriveKey", "deriveBits"], mandatoryUsages: ["deriveKey", "deriveBits"]},
- {name: "X448", resultType: "CryptoKeyPair", usages: ["deriveKey", "deriveBits"], mandatoryUsages: ["deriveKey", "deriveBits"]},
+ // {name: "X448", resultType: "CryptoKeyPair", usages: ["deriveKey", "deriveBits"], mandatoryUsages: ["deriveKey", "deriveBits"]},
Copy link
Member

Choose a reason for hiding this comment

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

Also, here, we can remove the commented-out lines.

Makefile Outdated
Comment on lines 10 to 12
build-debug:
go build -gcflags="all=-N -l"

Copy link
Member

Choose a reason for hiding this comment

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

Do we need to keep this? I believe this was for debugging your code.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I found it helpful while running the debugger and thought others may find it useful, but I'm happy to remove if you want to keep the Makefile cleaner.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think I'd prefer to remove this, as it looks like tool/use-case specific, like people versioning files like the configuration to run the debugger with VSCode. I understand both parties, and I'm no strong positioned, but if k6 have been kept with none of these, I'd prefer to keep it "clean".

I know in this case isn't exactly like that, because it's "purely Go", but for instance, in my particular case that I'm used to JetBrains IDEs and their debugger, I have never ever had the need to run this for debugging.

@McMastS McMastS requested a review from inancgumus April 9, 2025 17:16
@mstoykov
Copy link
Contributor

👋 Please rebase on latest master as #4701 is needed to see if the test are working.

Sorry for the inconvience 🙇

@McMastS
Copy link
Contributor Author

McMastS commented Apr 17, 2025

👋 Please rebase on latest master as #4701 is needed to see if the test are working.

Sorry for the inconvience 🙇

Looks like there are a few test failures here that these tests have caught! Thanks for fixing that @mstoykov

@mstoykov
Copy link
Contributor

Well that what tests are for :)

You can do it again as I decided to drop the need for buildign with tags. IME this helps a lot also with other tools as gopls wasn't really happy working with the tags being required. Unless you also set it up with those tags, which is extra steps.

@joanlopez
Copy link
Contributor

Hi @McMastS,

I see some WPTs are still failing, while there has been no new activity on this PR/branch since almost a month.
Are you planning to continue this work? If not, I'd suggest closing the PR, and opening it again if anytime you're interested again in finishing this contribution.

Thanks! 🙇🏻

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.

Support for Ed(X)25519
4 participants