- From: B Galliart <bgallia@gmail.com>
- Date: Thu, 23 Oct 2014 16:55:56 -0500
- To: public-webcrypto-comments@w3.org
- Message-ID: <CAGMK3zRi1GwSaMp_+ALoFM4+3FEPxvzCzM5ixdKTHXBZ==TY7Q@mail.gmail.com>
If I read the thread of Issue-24 correctly, the feeling of the working group that any synchronous API would lead to significant performance concerns. However, there should be some use cases for digest, importKey and sign where it should not be unreasonable to expect the use-case to complete in very tight time/processor constraints even on smart phones that are over a year old. I would like to purpose a method which allows the crypto API provider to specify the limits of what those use cases can be. Consider the following addition to the SubtleCrypto interface: Number syncMaxBytes(String method, AlgorithmIdentifier algorithm); So, if someone calls syncMaxBytes('digest', { name: 'SHA-1' }) and it returns 4096 then the script knows to make synchronous SHA-1 digest calls will require the CryptoOperationData to be less than or equal to 4096 bytes. On a different provider the value returned may be only 1024 due to limitations of resources or maybe it has enough resources to return 8192. Also, if the webcrypto provider decides any the call must always go through the Promise API then it could return a max of 0. So, syncMaxBytes('digest', { name: 'SHA-512' }) may result in 0 by a mobile browser that still supports SHA-512 through the asynchronous API but not via a synchronous call. Likewise, for methods importKey and sign, as long as the key and CryptoData lengths are kept limited, the time constraints on the call should be reasonable. The biggest problem I have with the current API is, if I understand it correctly, that it forces iteration to be recursive function calls which is limited by the maximum size of the call stack. I have found in some cases the call stack may be as small as 1,000. But there are several cases where the recommended number of iterations for uses of has and HMAC is recommended to be 5,000 or 10,000. For example, the current versions of Chrome provide generateKey and sign for performing a HMAC but not deriveKey/deriveBits for performing PBKDF2. Once the HMAC part of PBKDF2 is taken care of, the rest of the function is largely use of XOR and moving memory around. Hence, using nodejs's crypto module (which does allow synchronous function calls) to do the HMAC, performing all the rest of PBKDF2 returns results fairly quickly. Doing it in Chrome, despite it having the API functions to perform HMAC, is impossible. One might suggest just waiting for Chrome to provide deriveKey, but this isn't the only function impacted. What if a PBKDF3 is released which requires only minor tweaks but still has HMAC as the most costly part? Should there really be no way to provide an alternative method of performing it to allow for use on browsers that do not currently or will not be updated to support the new method? How about One Time Passwords where one of the recommended methods is to do multi-round re-hashing? Or being able to generate a SHA-256 crypt() hash on the client side based on Ulrich Drepper of Red Hat's specifications? Just because synchronous API's can be abused for large amounts of data which will take a long time to process, doesn't mean the standard should just throw the baby out with the bath water. It shouldn't be an all or none deal. There must be some compromise where the synchronous API use is kept limited to non-abusing situations so that iterative calls can still be done using a classic for loop.
Received on Thursday, 23 October 2014 22:29:49 UTC