Re: [Cfrg] Proposed Informational Note: Security Guidelines for Cryptographic Algorithms in the W3C Web Cryptography API

[Watson Ladd <[e-mail]>]

On Thu, Nov 20, 2014 at 7:38 AM, Harry Halpin <[e-mail]> wrote:
> Everyone,
>
> As the W3C Web Cryptography API gets ready to move to Candidate
> Recommendation, we wanted to address the concerns brought up by Rich
> Salz and others for better security guidelines for developers, given
> that the API exposes a variety of algorithms. I've taken Graham Steel's
> excellent write-up, which is in a large part based on Smart et al.'s
> magisterial ENISA report,  and have turned it into a draft CFRG note.
>
> We'd like to see the security guidelines below discussed here, and if
> there's no objections after discussion, move this onwards. W3C commits
> to maintaining this note as much as possible.
>
> Links to draft:
>
> TXT:
> http://www.w3.org/2012/webcrypto/draft-irtf-cfrg-webcrypto-algorithms-00.txt
> HTML:
> http://www.w3.org/2012/webcrypto/draft-irtf-cfrg-webcrypto-algorithms-00.html
>
> cheers,
>     harry
>

This says ECDSA is weak, and doesn't recommend future use Huh? MACs
are necessary for use with anything not AES-GCM, and this isn't
mentioned, nor is the correct way to compose described. The DH
description is just wrong: NFS has made a tremendous dent in the
security of genus 0 Diffie-Hellman. The security results for ECDH
cited aren't ones that actually matter.

There is no guidance on key size, which can make even the strongest scheme weak.

One might think HKDF2 is the right way to store a hashed password from
reading this. They would be wrong, as it's easy to search all
possibilities. PBKDF2 isn't much better, but you have a fighting
chance.

Other then that I didn't find any problems.

Sincerely,
Watson Ladd