Re: Regarding Issue-24: Defining a Synchronous API

Thank you for your fast reply!

Clearly my concern about stack size come from a misunderstand about what
constraints might be imposed by using a promise based API.

Are you aware of any example code which can perform PBKDF2 on Chrome
version 38?  Or any example code which does iterative rehashing without
recursion?

Thanks again



On Thu, Oct 23, 2014 at 5:36 PM, Ryan Sleevi <sleevi@google.com> wrote:

> There are no plans for any new synchronous APIs in the W3C. This is a
> decision for all APIs.
>
> It does not force iteration of recursive calls. Your concerns about stack
> size are unfounded.
> On Oct 23, 2014 3:30 PM, "B Galliart" <bgallia@gmail.com> wrote:
>
>> 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.
>>
>