Implement support for the subtle.encrypt feature
#24
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
oleiade
force-pushed
the
feature/encrypt
branch
2 times, most recently
from
5084bd4
to
0d3e32a
Compare
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.
Those functions are test helpers imported from the Web Platform Tests project: https://github.com/web-platform-tests/wpt/tree/master/WebCryptoAPI. We adapted them to suit our needs and play well in the context of the goja runtime.
oleiade
force-pushed
the
feature/encrypt
branch
from
0d3e32a
to
5153bc5
Compare
oleiade
force-pushed
the
feature/encrypt
branch
from
5153bc5
to
0fbf09f
Compare
They heavily depend on the importKey operation, thus, this is blocked by the importKey operation.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
馃毇 This is a work in progress, and is based on #9 馃毇
Checklist
feature/generate_keyis merged