| CryptoBuffer.cpp |
|
4471 |
| CryptoBuffer.h |
|
1840 |
| CryptoKey.cpp |
|
44270 |
| CryptoKey.h |
The internal structure of keys is dictated by the need for cloning.
We store everything besides the key data itself in a 32-bit bitmask,
with the following structure (byte-aligned for simplicity, in order
from least to most significant):
Bits Usage
0 Extractable
1-7 [reserved]
8-15 KeyType
16-23 KeyUsage
24-31 [reserved]
In the order of a hex value for a uint32_t
3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|~~~~~~~~~~~~~~~| Usage | Type |~~~~~~~~~~~~~|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Thus, internally, a key has the following fields:
uint32_t - flags for extractable, usage, type
KeyAlgorithm - the algorithm (which must serialize/deserialize itself)
The actual keys (which the CryptoKey must serialize)
|
7073 |
| KeyAlgorithmProxy.cpp |
|
8397 |
| KeyAlgorithmProxy.h |
|
3987 |
| moz.build |
|
966 |
| test |
|
|
| WebCryptoCommon.h |
|
12262 |
| WebCryptoTask.cpp |
|
121644 |
| WebCryptoTask.h |
The execution of a WebCryptoTask happens in several phases
1. Constructor
2. BeforeCrypto
3. CalculateResult -> DoCrypto
4. AfterCrypto
5. Resolve or FailWithError
6. Cleanup
If any of these steps produces an error (setting mEarlyRv), then
subsequent steps will not proceed. If the constructor or BeforeCrypto
sets mEarlyComplete to true, then we will skip step 3, saving the
thread overhead.
In general, the constructor should handle any parsing steps that
require JS context, and otherwise just cache information for later
steps to use.
All steps besides step 3 occur on the main thread, so they should
avoid blocking operations.
Only step 3 is guarded to ensure that NSS has not been shutdown,
so all NSS interactions should occur in DoCrypto
Cleanup should execute regardless of what else happens.
|
7562 |