Name Description Size
CryptoBuffer.cpp 4943
CryptoBuffer.h 1730
CryptoKey.cpp 33425
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) 6316
KeyAlgorithmProxy.cpp 7303
KeyAlgorithmProxy.h 3443
moz.build 870
test 25
WebCryptoCommon.h 10236
WebCryptoTask.cpp 103952
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. 7516