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

Robert Ransom <> Sat, 28 December 2013 02:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D04441AECBE for <>; Fri, 27 Dec 2013 18:15:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cyr7ClOOdv_D for <>; Fri, 27 Dec 2013 18:15:51 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c01::231]) by (Postfix) with ESMTP id 60A711AECBD for <>; Fri, 27 Dec 2013 18:15:51 -0800 (PST)
Received: by with SMTP id m20so9121680qcx.36 for <>; Fri, 27 Dec 2013 18:15:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zymS3+Rk4bUySxR+AXhpFBlapmSfJAelYY6xh+JPH/M=; b=a3c6aHEW7M7TlA69TTjAblKsHVJpuyPJm/DsPiuaAG9v120h9xTLKf3X5dHaAm8B49 fFIBn1cc7cmWkw8jPYJxZtTnnMD101QLFPtjJl+dX33K08x6ItfNqa4yMgshoydmm4EP V94RcdFAPs3E42b2NuDkjZO0XuWXxLdHCFu2d09hho6IlsRzGNdGDg0k6k7MS4fOl5bf RAsCZp0RjkDqExzAnHBBIuZlHJz5MXeVUHITF/E8L4bH39iPOLQqIiU+sEWA788AlrVz SxSX//OriC8N2HtbO7g7zLEl35sSYYo9rCCPN9LODKKU+WfqJk/+64Vy3LYkK2ltl7D/ licQ==
MIME-Version: 1.0
X-Received: by with SMTP id q13mr74040350qan.58.1388196946295; Fri, 27 Dec 2013 18:15:46 -0800 (PST)
Received: by with HTTP; Fri, 27 Dec 2013 18:15:46 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Fri, 27 Dec 2013 18:15:46 -0800
Message-ID: <>
From: Robert Ransom <>
To: David McGrew <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [Cfrg] Comments on draft-mcgrew-standby-cipher-00/draft-irtf-cfrg-cipher-catalog-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 28 Dec 2013 02:15:53 -0000

On 12/27/13, David McGrew <> wrote:

> (I'd like
> to see an AEAD algorithm based on salsa20 with poly1305, assuming that
> the consensus is that salsa20 is OK, and does not need to be swapped
> with chacha.)

ChaCha is faster than Salsa20, and also provides security with fewer
rounds.  There is no technical reason to prefer Salsa20 over ChaCha.

> My opinion: whatever application is making use of the cryptography
> should *not* have to deal with nonces.   Even if the algorithm requires
> distinct nonces, if we have a single encrypter per key, then it is
> trivial to have nonces generated inside of the crypto implementation,
> and have all of that complexity hidden from the calling application.

Tarsnap had a single process encrypting messages with each symmetric
key.  Its author accidentally removed the code to increment the nonce
between messages, and because its protocol sent the nonce explicitly
with each message, no one noticed the flaw for over a year (see

Never reuse a symmetric encryption *key* for more than one
non-interactive message or one interactive connection, and never send
an explicit nonce with any message -- use a fixed nonce for
non-interactive protocols, and use the message number as the nonce in
an interactive connection protocol.

Robert Ransom