-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
base: master
Are you sure you want to change the base?
Support for 25519 algos #4556
Conversation
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 ) |
There was a problem hiding this 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.
if normalizeAlgorithmName == ECDH { | ||
if err := ensureKeysUseSameCurve(privateKey, publicKey); err != nil { | ||
return NewError(InvalidAccessError, err.Error()) | ||
} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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"]}, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
+ // {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"]}, |
There was a problem hiding this comment.
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
build-debug: | ||
go build -gcflags="all=-N -l" | ||
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
👋 Please rebase on latest master as #4701 is needed to see if the test are working. Sorry for the inconvience 🙇 |
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. |
Hi @McMastS, I see some WPTs are still failing, while there has been no new activity on this PR/branch since almost a month. Thanks! 🙇🏻 |
What?
Adds support for
Ed25519
andX25519
algorithms in K6'swebcrypto
offering.This PR is still in draft, and I will add the following as I have time:
Why?
Checklist
make lint
) and all checks pass.make tests
) and all tests pass.Related PR(s)/Issue(s)
Closes #4263