Re: Dan Boneh's comments

Just realizing Dan's email was left out of the mailing list discussion.
Please make sure Dan sees your comments on his comments.

> 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
> entropy.
>
> 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 20:17:38 UTC