Regarding Issue-24: Defining a Synchronous API

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.