[Cfrg] Comments on draft-mcgrew-standby-cipher-00/draft-irtf-cfrg-cipher-catalog-01

Watson Ladd <watsonbladd@gmail.com> Tue, 24 December 2013 14:45 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id ABDAC1ADF75 for <cfrg@ietfa.amsl.com>; Tue, 24 Dec 2013 06:45:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.499
X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nNe4_mXKkNSG for <cfrg@ietfa.amsl.com>; Tue, 24 Dec 2013 06:45:57 -0800 (PST)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 234641ADF74 for <cfrg@irtf.org>; Tue, 24 Dec 2013 06:45:56 -0800 (PST)
Received: by mail-wi0-f172.google.com with SMTP id en1so12074261wid.17 for <cfrg@irtf.org>; Tue, 24 Dec 2013 06:45:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nzaCcBXpEGyObReZh5ZvSk9frreVOgjZEZA//URxuc0=; b=L8wCShjLjPRUv8Gi4tOrdg31y/N3GfIlvS10zgHyAlSMd5pi9vPfz4tEPWKiA/mIUC BnsEx41r8tlTEUznrhbrxmrhHHdyen+7YEF1xGz5xSletHXpvFNOTUgP/E8gYMwpxo4f zBnNlv7dchnmhFLB0k5KwHJVClxK3ib6xy2KkMQ2U3oR/4E0sjVTXVLkEGFQRK9/5Kx5 caYovARQvhd2kG0xjEcXtOFZLK45WHhjCf5Pxu5wrBZtSfZIom9gvXCBP+8jE0/aAeVk SvbL/24laeKHAbGwBHhKBKnc8n/2ekCYKTMh3+3CJiORucBWRcikbm0g51DG9A8pch2r mafQ==
MIME-Version: 1.0
X-Received: by with SMTP id k18mr23062712wic.44.1387896352914; Tue, 24 Dec 2013 06:45:52 -0800 (PST)
Received: by with HTTP; Tue, 24 Dec 2013 06:45:52 -0800 (PST)
Date: Tue, 24 Dec 2013 09:45:52 -0500
Message-ID: <CACsn0ckdQidBWgfGYn7YK7VmODq5+pVY8UZ6h1KC3g=mLqm2fQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: text/plain; charset=UTF-8
Subject: [Cfrg] Comments on draft-mcgrew-standby-cipher-00/draft-irtf-cfrg-cipher-catalog-01
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Tue, 24 Dec 2013 14:45:58 -0000

Dear all,
David McGrew invited us to comment on these, and since they cover
similar ground I decided to take them both on at once.

The basic problem I see is one is a bibliography and the other is a
wishlist. I don't see them
as being useful to someone simply asking the questions "what should I
use?" and "how do I
ensure algorithm agility is useful?"

The cipher catalog needs to be kept up to date, and I don't really see
a reasonable mechanism for doing it in the form of an internet draft.
Something along the lines of the X lounge, where X is hash function,
pairing, block cipher, stream cipher, or ala EFD/Safecurves is
probably a better format. It also needs a summary of the best attacks:
I should see something like "chosen ciphertext 2^36 texts, 2^192.5
time" for all ciphers, not just some. It's also missing Salsa20 and

The standby cipher document is a wishlist. It lists desirable
features, but doesn't propose any block cipher that can meet those
requirements. Instead it hopes that someone, somewhere will propose a
cipher that works.

That said these are the sorts of documents we need to see more of. I
personally think we should make a document "How to use a short shared
secret to protect a stream of messages", so as not to expose WGs to
the complexity of modes of operation.
It's a very solved problem, lots of protocols try to solve it, and
many get it wrong. Before I write a draft I'ld like to see if anyone
has strong objections to AES-GCM with counters for
nonces/XSalsa20+Poly1305 with counters for nonces. This is what is
deployed in Chrome, and both are fast on commodity chips and have
explicit security guarantees.

If possible both should be options: AES-GCM for speed on new Intel
chips, XSalsa20+Poly1305 on all other 32-bit chips with side channel