-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
PKI extension to crypto module [bounty: $650] #900
Comments
Link to bountysource: https://www.bountysource.com/issues/69000729-pki-extension-to-crypto-module-bounty-350 |
Submitted a PR for |
When I try to make a method under crypto |
Can you share some of the code, since I'm not sure exactly what you're trying to do. In general, the k6 code that binds Go methods to the goja JS runtime checks whether the first argument is a context or context pointer and passes that. |
Put up an example here: The target JS API is like this, with a subnamespace import { x509 } from "k6/crypto";
const pem = "pem-encoded-certificate";
const certificate = x509.parse(pem); In Go I've tried to do this by adding a struct field to
There's a test that can be run to see the error: go test -race github.com/loadimpact/k6/js/modules/k6/crypto |
In order for the I would recommend that you just make x509 to be You can probably hack around it with some changes to common.Bind ? Maybe having |
Thanks guys. If there are no objections, I'll head in this direction. |
The proposed change in API is totally fine with me. |
I have something toward this, with a certificate parsing successfully. But I'm having a casing issue. The output object ends up snake cased: { 'signature_algorithm': 'sha1WithRSAEncryption' } The API wants the standard JavaScript thing of camel casing: { signatureAlgorithm: 'sha1WithRSAEncryption' } Is there some way to achieve that? |
Found the way to do this with tags. Good feature. |
Submitted the certificate parsing piece of this in #1014. |
This has become larger than I can do under the bounty amount. Not sure how valuable it is, but I'm setting a target of $650 to take it through the rest. |
@bookmoons Thanks for letting us know. I've raised the bounty to $650 now so you can complete the project. |
Thank you very much. |
I'm also interested in this bug as it would be nice if I could generate signed JWTs other than HS256. There is RS256/PS256/EC256 signing methods and many oauth flows require a RS256 or PC256 signed JWT. |
@plambrechtsen this seems a bit out of scope for this issue. Can you create a new issue about it, linking to this issue? It would also need some evaluation, since I'm not sure which JWT parts would be better implemented as Go code and which parts should be implemented as a JS library that uses the Go crypto primitives @bookmoons has added in the PR. |
Hi @na-- thanks for that. As you can see I just created a new issue :) |
A question about data encoding. In signing for example we have this interface: const signer = createSign("SHA256");
signer.update(data, encoding); Elsewhere encoding is Does it make sense to also allow string messages for signing and encryption? const message = "Sent from my private space station orbiting Jupiter."
const signature = sign(priv, "SHA256", message); |
Maybe that doesn't really belong. Trying to fit decoding into decryption adds some complication. If we're treating them as primitives I guess people can handle encoding and decoding externally. |
|
|
Thank you, @bookmoons, for the awesome contribution! Unfortunately, as @robingustafsson has told you, we decided to wait a bit and further evaluate and benchmark some things before we proceed to expand the Go JavaScript API with the One of the main things we want to investigate is if we can fix the handling of binary data (#1020, #873) before we add any further crypto functions. They heavily depend on it, and lugging plain integer arrays is probably very inefficient and definitely very cumbersome. Also, since having a custom k6-specific crypto API won't help k6 with the adoption of JS libraries from the broader JS ecosystem that depend on either the WebCrypto API or on the Node.js crypto module, we want to benchmark and evaluate where exactly we fall short on performance when polyfills for those are used. Depending on what we find, we may end up re-writing the crypto module to be a Go polyfill for parts of the Web crypto API or something like that... |
Discussion about how this should actually be implemented (among other stuff) is moved to #2248 |
Hey guys, not sure where to ask this, but I'm wondering if I need to do ECDSA signing, what's the best approach as things stand now? I saw the signing PR didn't get merged, and xk6-crypto doesn't look to have signing support either. I'm guessing my best bet is to transpile a nodejs or plainjs crypto library? |
Pure JS crypto libraries will probably work, though the performance will likely be quite terrible 😞 You can also add it to the xk6-crypto extension, it should be fairly easy to do: https://pkg.go.dev/crypto/ecdsa |
We want to extend the k6 crypto module with support for PKI crypto. This will mean adding functionality to generate cryptographically strong random numbers, read/parse x.509 certificates, read/parse PEM encoded keys, signing/verifying and encrypting/decrypting data. We want to support PKCS#1 version 1.5, PKCS#1 version 2 (also referred to as PSS and OAEP), DSA and ECDSA.
Related issues:
Requirements
Besides the user-facing JS APIs detailed below a completed bounty must also include tests and docs.
Generate cryptographically strong random numbers
Proposal for JS API
Relevant links:
Parsing x.509 encoded certificates
Proposal for JS API (shorthand):
Proposal for JS API (full):
The Certificate object returned by x509.parse() should return a an Object with the following structure:
Relevant links:
Signing/Verifying data (RSA)
Proposal for JS API (shorthand version):
[LOWER PRIO] Proposal for JS API (full version):
Relevant links:
Signing/Verifying data (DSA)
The API would be the same for sign/verify as for RSA, the type of encryption used would be inferred by the keys used, so by the following lines:
Relevant links:
Signing/Verifying data (ECDSA)
The API would be the same for sign/verify as for RSA, the type of encryption used would be inferred by the keys used, so by the following lines:
Relevant links:
Encrypt/Decrypt data (RSA)
Proposal for JS API:
Relevant links:
The text was updated successfully, but these errors were encountered: