Name Description Size
CryptoBuffer.cpp 4471
CryptoBuffer.h 1840
CryptoKey.cpp 44278
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 12273
WebCryptoTask.cpp 121792
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