W3C home > Mailing lists > Public > public-webcrypto@w3.org > September 2013

Dan Boneh's comments

From: Harry Halpin <hhalpin@w3.org>
Date: Mon, 30 Sep 2013 20:44:03 +0100
Message-ID: <c2068acb92a079c22e0f4c7ccb38975c.squirrel@webmail-mit.w3.org>
To: public-webcrypto@w3.org
He said he'll make the comments in person on the phone.

Section 5:
Section 5.2, 3rd paragraph:   might be worth mentioning that, in addition
to secret keys, end-users may also have direct access to decrypted data.

Section 5.2:  Should the section mention that implementations need access
to unpredictable randomness?   Some user agents may not have sufficient

Similarly, it might be worth adding a note in Section 9 saying that
getRandomValues and generateKey may fail with "InsufficientEntropyError" to
indicate that the generator currently does not have sufficient entropy
to satisfy the request.

Section 13:
The encrypt interface seems to be missing some key parameters.    For
symmetric encryption I would suggest expanding it to

Promise<any> encrypt(AlgorithmIdentifier algorithm,
                       Key key,
                       Nonce nonce,
                       sequence<CryptoOperationData> associatedData);
                       sequence<CryptoOperationData> cleartextData);

As is, the Nonce and associatedData arguments are missing.   As a result,
in several modes the IV and associatedData are given as parameters to the
algorithms.   I worry that this will confuse developers into thinking that
the IV and associatedData are set once when the key is initialized and
never changed again.   But both, especially the nonce, will need to be
different for every message.

Similarly, AES-GCM decrypt will need to take as input the ciphertext *and*
associatedData. Would associatedData always be given as an algorithm
parameter?   Seems a bit odd to put them there.

Section 17 (algorithms):
(1) I know you warned me about this, but the use of the words "Recommended
algorithms" is somewhat confusing, especially since the list includes
several weak algorithms.     Any chance the section can be titled
"Recommended algorithms for backwards compatibility" ?

(2)  IDL and operations for DH and ECDH should be almost the same, but
currently they are quite different.

(3)  I didn't see access to Raw-AES.   There are cases where that is
needed, e.g. for implementing unsupported modes such as SIV and FFX.

(4)  It is likely that there will soon be a need to extend the list of
curves for ECDH and ECDSA.   How would this affect the design?

(5) Why is AES-CFB on the list?

(6)  For PBKDF2, should some guidance be given as to how to choose the
number of iterations?    If developers set it too high it may be too slow
on slow user agents.   If they set it too low to accommodate all user
agents it will hurt security.

(7)  Should signatures with message recovery be supported?    (e.g.
SR-RSA-PSS)    I'm guessing that answer is no, but wanted to bring it up.

Section 19.2:
I would encourage the authors to not give AES-CBC as example code.   This
should be changed to AES-GCM.   AES-CBC should not be used for encryption.
Received on Monday, 30 September 2013 19:44:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:19 UTC