Vendor and modularize the portions of the SJCL necessary for SHA-256 HMAC and CSPRNG #17
Conversation
packages/crypto-sjcl-aes/index.d.ts
Outdated
| import {BitArray} from '@aws/crypto-sjcl-bitArray'; | ||
|
|
||
| declare class aes { | ||
| constructor(key: BitArray); |
There was a problem hiding this comment.
Can you add the comments from the JSDoc here too?
| //check to make sure the bitLength is divisible by 8, if it isn't | ||
| //we can't do anything since arraybuffers work with bytes, not bits | ||
| if ( sjcl.bitArray.bitLength(arr)%8 !== 0 ) { | ||
| throw new sjcl.exception.invalid("Invalid bit size, must be divisble by 8 to fit in an arraybuffer correctly"); |
There was a problem hiding this comment.
I don't think we have sjcl.exception defined in this file.
| touchCollector: this._bind(this._touchCollector) | ||
| }; | ||
|
|
||
| if (window.addEventListener) { |
There was a problem hiding this comment.
Will this work in environments where there isn't a window object? Thinking of react native and web workers specifically.
There was a problem hiding this comment.
This particular function will not work in those environments.
All CSPRNGs require some form of truly random seed, and startCollectors is only called if that seed is not supplied. Further down in the file, there's an IIFE that attempts to seed the algorithm by calling (in order of preference) require('crypto').randomBytes, window.crypto.getRandomValues, and window.msCrypto.getRandomValues -- random collection via event listeners is only attempted if all of those methods fail.
Packages that consume the SJCL random generator will need to be aware of this, but there really isn't anything we can do about it. Without a random seed, the Fortuna algorithm is useless.
| ol = this._length, | ||
| nl = this._length = ol + sjcl.bitArray.bitLength(data); | ||
| if (nl > 9007199254740991){ | ||
| throw new sjcl.exception.invalid("Cannot hash more than 2^53 - 1 bits"); |
There was a problem hiding this comment.
Need to import exception in this file too.
…HMAC and CSPRNG (#17) * Vendor and modularize the portions of the SJCL necessary for SHA-256 HMAC and CSPRNG * Ensure comments and exceptions are present * Ensure the SJCL random module does not throw reference errors
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread. |
Spun off from #1
The Stanford JavaScript Crypto Library is trusted, reasonably performant, and does not make any assumptions about the environment on which it's running, but it binds all functions to a global variable, has no built-in typings, and is quite large when included in its entirety. This PR takes the files necessary for
sjcl.misc.hmacandsjcl.random(as determined by the dependency tree provided here), converts them to CommonJS modules, and adds TypeScript declaration files.