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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement support for the subtle.generateKey operation #26

Closed
wants to merge 11 commits into from

Conversation

oleiade
Copy link
Member

@oleiade oleiade commented Nov 29, 2022

This PR addresses #13 and implements the subtle.generateKey operation.

It implements the function according to the W3C specification, and offers the following API.

The PR contains extensive usage examples offered by the functionalities of this PR, but here's a quick, illustrative example, of an ECDSA key pair generation:

import { crypto } from "k6/x/webcrypto";

export default function () {
  crypto.subtle
    .generateKey({ name: "ECDSA", namedCurve: "P-256" }, true, [
      "sign",
      "verify",
    ])
    .then((key) => {
      console.log(JSON.stringify(key));
    });
}

I'm sure there are many potential improvements possible left for this, and I'm looking forward to hearing from you 馃檱馃徎

@mostafa, I added you as an optional reviewer; if you have time, could you please take a quick look to ensure I haven't done something wrong on the key generation part? The code for those live in the aes.go, rsa.go, elliptic_curve.go and hmac.go files (GenerateKey functions).

@oleiade oleiade added the enhancement New feature or request label Nov 29, 2022
@oleiade oleiade requested a review from mostafa November 29, 2022 07:45
@oleiade oleiade self-assigned this Nov 29, 2022
Copy link
Contributor

@olegbespalov olegbespalov left a comment

Choose a reason for hiding this comment

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

I did an initial round of review, but I believe the current approach should be adjusted by introducing the Algorithm interface, a constructor for specific algorithms, and so on.

webcrypto/aes.go Outdated Show resolved Hide resolved
webcrypto/aes.go Outdated Show resolved Hide resolved
webcrypto/elliptic_curve.go Outdated Show resolved Hide resolved
webcrypto/subtle_crypto.go Outdated Show resolved Hide resolved
@oleiade oleiade force-pushed the feature/generate_key branch 10 times, most recently from 4c4d817 to 110e558 Compare December 14, 2022 16:51
Copy link
Member

@mostafa mostafa left a comment

Choose a reason for hiding this comment

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

LGTM!

webcrypto/aes.go Show resolved Hide resolved
webcrypto/elliptic_curve.go Show resolved Hide resolved
@oleiade oleiade requested a review from mstoykov March 9, 2023 13:29
In order to ease integration into k6 (which is compatible with  Go
up to version 1.18), we set our target Go version to 1.18.
This commit is an a almost verbatim (curated) copy of the Web Platform
Tests for the WebCryptoAPI:
https://github.com/web-platform-tests/wpt/tree/master/WebCryptoAPI

We've also (imported and) adapted some of their helpers  to suit our
needs and play well in the context of the goja runtime.
This commit splits the Algorithm Normalization algorithm away from the
algorithm.go file into a dedicated normalization.go file. The reasoning
behind that was that we do all sorts of normalization and validation in
the context of the project, and it would be more thematic and easier to
maintain/comprehend if those functions and types lived in a dedicated
file.
The SubtleCrypto.generateKey() operation allows user to produce
cryptographic random keys of various types. They return a CryptoKey object
which holds, besides key-related information, a private handle on the
key's bytes.

As described in the specification:
https://www.w3.org/TR/WebCryptoAPI/#SubtleCrypto-method-generateKey

And as demonstrated here:
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/generateKey
It is a common need in the WebCrypto implementation, beyond simply
generating keys, to be able to easily produce the intersection of two
sets, or two check if a slice contains a given value. This commit
introduces two helpers to do just that.
In order to decide on which usages a generated CryptoKey is valid for,
we needed a way to quickly find out the allowed usages for each key
format. Inside a given algorithm kind (Rsa, ECDSA, ECDH, etc), different
cipher, and whether the key is public or private, allow for different
usages too.

This commit introduces a method holding a table to obtain this
information from an algorithm name, and crypto key type.
This is a cleanup commit getting rid of miscelaneous changes that are
not justified anymore.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants