Re: ChaCha20-Poly1305 for SSH

nisse@lysator.liu.se (Niels Möller ) Sun, 29 November 2015 18:05 UTC

Return-Path: <bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org>
X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18551B2BFA for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Sun, 29 Nov 2015 10:05:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.185
X-Spam-Level:
X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=ham
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 LkBXi1otnbmP for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Sun, 29 Nov 2015 10:05:46 -0800 (PST)
Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793241B2BDD for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Sun, 29 Nov 2015 10:05:46 -0800 (PST)
Received: by mail.netbsd.org (Postfix, from userid 605) id 10AA314A243; Sun, 29 Nov 2015 18:05:46 +0000 (UTC)
Delivered-To: ietf-ssh@netbsd.org
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id AE0DD14A394 for <ietf-ssh@netbsd.org>; Sun, 29 Nov 2015 18:05:40 +0000 (UTC)
X-Virus-Scanned: amavisd-new at NetBSD.org
Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id MDhMe2GFdPUv for <ietf-ssh@netbsd.org>; Sun, 29 Nov 2015 18:05:40 +0000 (UTC)
Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id D94A514A243 for <ietf-ssh@netbsd.org>; Sun, 29 Nov 2015 18:05:37 +0000 (UTC)
Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id EDE5F40037; Sun, 29 Nov 2015 19:05:34 +0100 (CET)
Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id A03F340036; Sun, 29 Nov 2015 19:05:33 +0100 (CET)
Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Sun, 29 Nov 2015 19:05:33 +0100
From: nisse@lysator.liu.se
To: Damien Miller <djm@mindrot.org>
Cc: Simon Josefsson <simon@josefsson.org>, ietf-ssh@netbsd.org
Subject: Re: ChaCha20-Poly1305 for SSH
References: <87egfdxebo.fsf@latte.josefsson.org> <nny4dksr3i.fsf@armitage.lysator.liu.se> <alpine.BSO.2.20.1511292239430.12629@natsu.mindrot.org>
Date: Sun, 29 Nov 2015 19:05:33 +0100
In-Reply-To: <alpine.BSO.2.20.1511292239430.12629@natsu.mindrot.org> (Damien Miller's message of "Sun, 29 Nov 2015 22:42:10 +1100 (AEDT)")
Message-ID: <nnegf8smtu.fsf@armitage.lysator.liu.se>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: ClamAV using ClamSMTP
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list

Damien Miller <djm@mindrot.org> writes:

> IMO if you're going to the trouble of preserving packet length
> privacy then you should do it properly and use a separate cipher
> instance to do it.

Does it matter if we xor it with some unused bytes in the same chacha
key stream used for the rest of the data, or use a separate instance
with a different key (but generated from the same key exchange secret)?

> In the case of chacha20, it's ridiculously cheap
> to do so; the cipher has negligible state.

It just seems nice to me to not have to produce yet another session key
just for this, when we have 32 perfectly good key stream bytes left
over. I agree the per-message overhead with an extra chacha instance is
very low, and it's no big deal, it's more about eliminating a little
book-keeping.

Or are you suggesting the even more proper thing to do, which would be
to encrypt the length field *and* add separate authentication tag for
it?

Off the top of my head, I think it would make sense with some
building-block which takes as input a per-session key, the 32-bit
length, and per-message nonce, and produces, e.g., 64 random looking
output bits, such that (1) the length can be recovered only by the
receiver, with whome we share the key, and (2) any malicious
modification of the 64 bits on the wire can be detected with probability
close to 1. Or just use a separate chacha-poly1305 on the length, with
it's larger tag.

Regards,
/Niels


-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.