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

Jonathan Berliner <jberliner@caa.columbia.edu> Thu, 20 November 2014 16:25 UTC

Return-Path: <jonathan.berliner@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3310C1A1AAC for <cfrg@ietfa.amsl.com>; Thu, 20 Nov 2014 08:25:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGGwwI1_g9Jc for <cfrg@ietfa.amsl.com>; Thu, 20 Nov 2014 08:25:14 -0800 (PST)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03BD1A1ABB for <cfrg@irtf.org>; Thu, 20 Nov 2014 08:25:13 -0800 (PST)
Received: by mail-pa0-f54.google.com with SMTP id fb1so2822285pad.41 for <cfrg@irtf.org>; Thu, 20 Nov 2014 08:25:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0KZa6GWP18QVVbs9Ii6BzD2MChcxwJPsUWf7U7G3zDc=; b=ba1EzYh6+2LXk+fVV3vIAijELA06VZQkCWpoxkgn+pvQZ9eWQ1jH2MIdOdLM9VMR12 RVAhVLtM5wPrQ/2KKGiFXMUzWwRXVzYvizGhT4jjBS+BhxbEQoj0TwRj498R4K9wNlCu hDuuGNFwrpSoWQNAOVYfyfrHj4K93xNrDStjw1cS1h2LNobUgi8G4uP7Sid4FWOAeNPD tx5HmiXhl3kNzkDY9EkqsTzuAKvvk7juN1Whh7i6lMKKlHB4Wes1ltB9jp2eKtfcUm4m Oh5BRpduPQ6Q9Y+PcUiFZuSid5HVsKyliZazbgOorvrvSAwr769Yb+cn3hIHGTqxJUJo io1A==
X-Received: by 10.68.220.39 with SMTP id pt7mr56484430pbc.37.1416500712213; Thu, 20 Nov 2014 08:25:12 -0800 (PST)
MIME-Version: 1.0
Sender: jonathan.berliner@gmail.com
Received: by 10.70.53.9 with HTTP; Thu, 20 Nov 2014 08:24:42 -0800 (PST)
In-Reply-To: <CACsn0cn+KX9J1NSUFhKV32iWL4KLHEPOKcXea3cD20QK2YeeaA@mail.gmail.com>
References: <546E0AE5.3040601@w3.org> <CACsn0cn+KX9J1NSUFhKV32iWL4KLHEPOKcXea3cD20QK2YeeaA@mail.gmail.com>
From: Jonathan Berliner <jberliner@caa.columbia.edu>
Date: Thu, 20 Nov 2014 11:24:42 -0500
X-Google-Sender-Auth: 7A5UVCxhHQjUiCl74GQFCkJkngA
Message-ID: <CAP4fkhhBs1QHj5OFoukJdBt2L=EL0PEZ8yefC8S-JRFM=4WX=Q@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Uv-kQMLBdFxeQ2ZAm_3QcC0sk6g
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Proposed Informational Note: Security Guidelines for Cryptographic Algorithms in the W3C Web Cryptography API
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: jberliner@caa.columbia.edu
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Nov 2014 16:25:23 -0000

I'm relatively new to this group so take this with some salt, but this
bothered me:

I don't like the usage of "nonce" and "random" in these sentences:
"AES-CBC mode is not CCA secure. It is secure against chosen plaintext
attacks (CPA-secure) if the IV is random, but not if the IV is a
nonce[rogaway11evaluation]."

"AES-CFB is not CCA secure. It is CPA-secure if the IV is random, but
not if the IV is a nonce [rogaway11evaluation]."

I read Rogaway's paper
(http://web.cs.ucdavis.edu/~rogaway/papers/modes.pdf), but I think we
can define this better:

"Nonce" - a value/number/string used only once.
"Random number" - a value/number/string that doesn't follow a pattern
(or what-have-you).

This doesn't mean that "nonces" are insecure. "Non-random nonces" are
insecure, but "random nonces" are secure. According to the flow of the
document, "random IVs" are also insecure, because they may be used
more than once.

I think I understood Rogaway's intent here, that non-randomness is the
problem, not one-timeness. Based on a cursory survey of parlance used
on the Internet, I think others would be confused by this, because
"nonces" can also be "random."

Jonathan


On Thu, Nov 20, 2014 at 11:00 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
> On Thu, Nov 20, 2014 at 7:38 AM, Harry Halpin <hhalpin@w3.org> 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
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg