From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 20 01:18:58 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3886312D6CE for ; Wed, 20 Apr 2016 01:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.296 X-Spam-Level: X-Spam-Status: No, score=-5.296 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stbuehler.de 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 MqzLX7-T6uEO for ; Wed, 20 Apr 2016 01:18:54 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 D971312B05F for ; Wed, 20 Apr 2016 01:18:51 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 38F8E85F03; Wed, 20 Apr 2016 08:18:51 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 1EDB985EC0 for ; Wed, 20 Apr 2016 08:18:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=stbuehler.de 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 rjoUjyzqKNmU for ; Wed, 20 Apr 2016 08:18:46 +0000 (UTC) Received: from mail.stbuehler.de (stbuehler.de [IPv6:2a01:4f8:a0:2276::2]) (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 D207A84CEE for ; Wed, 20 Apr 2016 08:18:45 +0000 (UTC) Received: from chromobil-cert.local (unknown [IPv6:2a02:8070:a1be:1600:faca:b8ff:fe3a:723]) by mail.stbuehler.de (Postfix) with ESMTPSA id A1D72B803BA for ; Wed, 20 Apr 2016 08:18:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=stbuehler.de; s=stbuehler1; t=1461140319; bh=iUx4Iz7VzTy/cV+dlVKOb0THS2aG0OaxB3dDVeG2yvs=; h=Date:From:To:Subject:From; b=metjDCjk9E4dcRJK6DlwPiyi6OsVD7N0ITT+55vLtLokGolPa6pjwR/LYxrVQ1NXA zdQ76fbACquGfY2FXX+RJ/DeE2ToFr5eTTRTb01TTltadmv9+KQGb2RYUkUzNGtF52 En+dXh9t6kCyG76SpeChVanGNE86pF672I9L29x8= Date: Wed, 20 Apr 2016 10:18:38 +0200 From: Stefan =?UTF-8?B?QsO8aGxlcg==?= To: ietf-ssh@netbsd.org Subject: Re: ChaCha20-Poly1305 for SSH Message-ID: <20160420101838.5861b73d@chromobil-cert.local> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi, some time ago I tried implementing ssh-chacha20-poly1305@openssh on my own and was rather disappointed by the state of the documentation in openssh (in the end the source code told me what I needed to know). Seeing draft-josefsson-ssh-chacha20-poly1305-openssh-00 I hoped there would be some improvement... but well, it is just a copy of the openssh file :) So I started to work on it, and also read some of the following discussion on ietf-ssh. A large part of the discussion spun off discussing a whish list for a new binary packet protocol; changing the binary packet protocol probably requires rewriting core logic in many SSH implementations, so this should be done very carefully and not just for one cipher, and I somehow doubt it will happen soon. So I propose defining "chacha20-poly1305" as either the existing "chacha20-poly1305@openssh.com" or as a slightly modified variant: - using AEAD_CHACHA20_POLY1305 from RFC7539 - encrypt the packet length with otherwise discarded bytes from the first Chacha20 block, i.e. only a single Chacha20 instance - pad the nonce to 12 bytes with zeroes on the left side, so one can simply reuse the original Poly1305 implementation with a 8-byte nonce. - openssh patch: https://github.com/rus-cert/openssh-portable/tree/feature-chacha20-poly1305 The "full" documents can be found here: https://github.com/rus-cert/ssh-chacha20-poly1305-drafts It would be nice to get some feedback on whether there is interest in getting "chacha20-poly1305" out before a protocol redesign and which variant to go for. If there is no interest in getting an RFC for this maybe at least the openssh devs are interested in fixing their documentation :) --- As far as I could see the following questions were raised in the context of the original draft announcement and some later AEAD discussions. My comments on them should explain why I think the openssh variant is basically ok, and why I wouldn't pull more changes into a modified version than I did above. - Whether to use the Poly1305 data construction from RFC7539: At first I thought the Poly1305 usage in "chacha20-poly1305@openssh.com" is vulnerable to some length modifications; but then I remembered that Poly1305 uses an explicit termination in the padding. As the length of the AAD is fixed I see no security gain changing to the method described in RFC7539. - Whether it is necesary to encrypt the packet length field: Some voiced a strong preference for this as a requirement to prevent traffic analysis. It was pointed out the encrypted could lead to some extra attack surface (or has done so in other protocols in the past), but I think it is safe in the context of Chacha20. I see nothing an attacker could gain here compared to not encrypting the length. - Encrypting the packet length using otherwise discarded bytes from the Chacha20 block used for the Poly1305 key: It is a nice idea which can be used to optimize both performance and memory usage. - Binary packet protocol rethink: This is certainly worth exploring, but I don't think this needs to be completed before "chacha20-poly1305" becomes official. I think a new family of algorithms could be started with a different binary packet protocol, or even a new SSH protocol version. (My idea for a new protocol: separate encryption framing and inner message framing. No need to hide the outer packet length anymore.) - Changing padding requirements, authentication of the encrypted length: I see no need to change this in the context of a single algorithm. Belongs into a more generic protocol redesign. Cheers, Stefan From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 21 12:16:21 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5280412E17B for ; Thu, 21 Apr 2016 12:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 uGiBX5BOVSsN for ; Thu, 21 Apr 2016 12:16:19 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 5C48D12E107 for ; Thu, 21 Apr 2016 12:16:19 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id EB93A85F06; Thu, 21 Apr 2016 19:16:06 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 8C5DF85E54 for ; Thu, 21 Apr 2016 19:16:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id UhJeBt-iZJ8s for ; Thu, 21 Apr 2016 19:16:01 +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 4841A85DFE for ; Thu, 21 Apr 2016 19:15:59 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id A2D4B40017; Thu, 21 Apr 2016 21:15:56 +0200 (CEST) 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 727494000E; Thu, 21 Apr 2016 21:15:55 +0200 (CEST) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Thu, 21 Apr 2016 21:15:55 +0200 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Stefan =?utf-8?Q?B=C3=BChler?= Cc: ietf-ssh@netbsd.org Subject: Re: ChaCha20-Poly1305 for SSH References: <20160420101838.5861b73d@chromobil-cert.local> Date: Thu, 21 Apr 2016 21:15:55 +0200 In-Reply-To: <20160420101838.5861b73d@chromobil-cert.local> ("Stefan =?utf-8?Q?B=C3=BChler=22's?= message of "Wed, 20 Apr 2016 10:18:38 +0200") Message-ID: 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 Stefan B=C3=BChler writes: > Seeing draft-josefsson-ssh-chacha20-poly1305-openssh-00 I hoped there > would be some improvement... but well, it is just a copy of the openssh > file :) I think Simon's intention was percisely to document what openssh does. I hope you've also seen draft-nisse-secsh-aead-00. I'm replying looking for ways to improve that and move forward.=20 > A large part of the discussion spun off discussing a whish list for a > new binary packet protocol; [...] and I somehow > doubt it will happen soon. Agreed. > - pad the nonce to 12 bytes with zeroes on the left side, so one can > simply reuse the original Poly1305 implementation with a 8-byte nonce. I'm not following you here. And I'm not sure what you mean by "original pol= y1305". Poly1305-AES as defined in http://cr.yp.to/mac/poly1305-20050329.pdf? Or the salsa20-poly1305 described in http://cr.yp.to/highspeed/naclcrypto-20090310.pdf, which I think is what chacha-poly1305 evolved from? I don't think either uses an 8-byte nonce. > - Whether to use the Poly1305 data construction from RFC7539: > > At first I thought the Poly1305 usage in > "chacha20-poly1305@openssh.com" is vulnerable to some length > modifications; but then I remembered that Poly1305 uses an explicit > termination in the padding. As a crypto library author, I'd really prefer if there were a single definition of chacha-poly1305 used in all applications. But that's maybe not a very compelling argument for ssh protocol design. There may also be reasons of ietf politics to stick to ietf's definition. > As the length of the AAD is fixed I see no security gain changing to > the method described in RFC7539. I'm also unaware of any difference in security. > - Whether it is necesary to encrypt the packet length field: > > Some voiced a strong preference for this as a requirement to prevent > traffic analysis. > > It was pointed out the encrypted could lead to some extra attack > surface (or has done so in other protocols in the past), but I think > it is safe in the context of Chacha20. I see nothing an attacker could > gain here compared to not encrypting the length. My quite strong opinion is that we shouldn't force others to choose between encrypted packet lengths, and using chacha-poly1305. And when writing a specification which mentions this topic, I'd like to recommend that other AEAD ciphers also encrypt the packet lengths, and give some clear guidance on how to do it properly. > - Encrypting the packet length using otherwise discarded bytes from the > Chacha20 block used for the Poly1305 key: > > It is a nice idea which can be used to optimize both performance and > memory usage. I agree it's a nice idea. I didn't go that way in my draft, because (i) the optimization is minor, a single chacha_core operation and very small state, and (2) because it's very algorithm specific, it doesn't generalize to other AEAD ciphers. I'd be happy to change, if there is support for this idea. Also note that it's straightforward to this based on a pure RFC5116-style interface to chacha-poly1305, which doesn't output the additional bytes of the first block: simply run chacha20 one more time to get the bytes used for length encryption. No less efficient than using a separate chacha instance, like openssh is doing. > - Changing padding requirements, authentication of the encrypted length: > > I see no need to change this in the context of a single algorithm. > Belongs into a more generic protocol redesign. I'm afraid some tweaks to the padding requirements are needed even if you only think of chacha-poly1305, the original padding rules don't make much sense when the length isn't encrypted in the same way as the rest of the payload. And I think it's desirable to have AEAD ciphers in ssh do things the same way. It's a bit annoying, because the details aren't terribly important, but it has to be nailed down, and I have difficulty finding a way that isn't a bit ugly in one way or the other. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Apr 22 03:57:50 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31ECC12E694 for ; Fri, 22 Apr 2016 03:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.296 X-Spam-Level: X-Spam-Status: No, score=-5.296 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stbuehler.de 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 UCgOoFZV2kyH for ; Fri, 22 Apr 2016 03:57:48 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 0A6A512E68B for ; Fri, 22 Apr 2016 03:57:48 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 88AE085E96; Fri, 22 Apr 2016 10:57: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 6278285E58 for ; Fri, 22 Apr 2016 10:57:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=stbuehler.de Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 1krWsfAc8SWy for ; Fri, 22 Apr 2016 10:57:39 +0000 (UTC) Received: from mail.stbuehler.de (stbuehler.de [IPv6:2a01:4f8:a0:2276::2]) (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 E60F484CEE for ; Fri, 22 Apr 2016 10:57:37 +0000 (UTC) Received: from chromobil-cert.local (unknown [82.113.98.240]) by mail.stbuehler.de (Postfix) with ESMTPSA id 9F412B80426; Fri, 22 Apr 2016 10:57:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=stbuehler.de; s=stbuehler1; t=1461322654; bh=g7ZkacO9SCLith4+Mfn9eyN11AujEptZU4QCsax7Q7k=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=nM3GSUDSPP1m56Gbmt2xOjM2Up22Iud+Vke/wOhM08ZrOpsCCFAZJlNTSidK9S9P0 sHFcNKYcGdfOE7mEDlH2qQfR1Kqu4KGemVZa9waCWD8D9wHLM/tw1rLXuUHXmuOEKq AK+YsTlJGuypuhbIWA6YYqWxENFfMGgzWP19rwo0= Date: Fri, 22 Apr 2016 12:57:31 +0200 From: Stefan =?UTF-8?B?QsO8aGxlcg==?= To: ietf-ssh@netbsd.org Cc: nisse@lysator.liu.se (Niels =?UTF-8?B?TcO2bGxlcg==?=) Subject: Re: ChaCha20-Poly1305 for SSH Message-ID: <20160422125731.56e804dc@chromobil-cert.local> In-Reply-To: References: <20160420101838.5861b73d@chromobil-cert.local> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Niels, thanks for your feedback! On Thu, 21 Apr 2016 21:15:55 +0200 nisse@lysator.liu.se (Niels M=C3=B6ller) wrote: > Stefan B=C3=BChler writes: > [...]=20 >=20 > I hope you've also seen draft-nisse-secsh-aead-00. I'm replying > looking for ways to improve that and move forward.=20 My feeling is that this document already is the "protocol rethink" (and not just a "small algorithm family"), because: - a "protocol rethink" would only allow AEAD anyway - when core packet handling is changed it should be done right in the first place So let me repeat my idea for a new protocol here: I'd separate the cryptographic message framing from the SSH message framing. That way one could really use "any" standard AEAD interface without the need to specify how the packet length is encrypted with each single AEAD, simpler nonce generation, ... > [...] > > - pad the nonce to 12 bytes with zeroes on the left side, so one can > > simply reuse the original Poly1305 implementation with a 8-byte > > nonce. =20 >=20 > I'm not following you here. And I'm not sure what you mean by > "original poly1305". Poly1305-AES as defined in > http://cr.yp.to/mac/poly1305-20050329.pdf? Or the salsa20-poly1305 > described in http://cr.yp.to/highspeed/naclcrypto-20090310.pdf, which > I think is what chacha-poly1305 evolved from? I don't think either > uses an 8-byte nonce. Oh my... sorry. I meant Chacha20 of course; DJBs original definition uses a little-endian 64-bit block-counter and a 64-bit nonce (often the packet counter). RFC7539 moves the trailing 4 bytes from the block counter (which are almost always zero - no packet is that big) and prepends them to the nonce in the interface (but does the same thing internally) to get the "standard" 12-byte nonce interface. (This also applies to how the Salsa20 streaming function in naclcrypto-20090310.pdf is applied. Chacha20 copies the definition of the 16-byte input from Salsa20.) Also see how I didn't need to change the Chacha20 nonce or implementation for the openssh patch. > > - Whether to use the Poly1305 data construction from RFC7539: > > > > At first I thought the Poly1305 usage in > > "chacha20-poly1305@openssh.com" is vulnerable to some length > > modifications; but then I remembered that Poly1305 uses an > > explicit termination in the padding. =20 >=20 > As a crypto library author, I'd really prefer if there were a single > definition of chacha-poly1305 used in all applications. But that's > maybe not a very compelling argument for ssh protocol design. There > may also be reasons of ietf politics to stick to ietf's definition. Yes, I'd prefer that too. But is the preference important enough to modify an already existing protocol? > [...]=20 > > - Whether it is necesary to encrypt the packet length field: > > > > Some voiced a strong preference for this as a requirement to > > prevent traffic analysis. > > > > It was pointed out the encrypted could lead to some extra attack > > surface (or has done so in other protocols in the past), but I > > think it is safe in the context of Chacha20. I see nothing an > > attacker could gain here compared to not encrypting the length. =20 >=20 > My quite strong opinion is that we shouldn't force others to choose > between encrypted packet lengths, and using chacha-poly1305. And when > writing a specification which mentions this topic, I'd like to > recommend that other AEAD ciphers also encrypt the packet lengths, > and give some clear guidance on how to do it properly. Sounds good to me. > > - Encrypting the packet length using otherwise discarded bytes from > > the Chacha20 block used for the Poly1305 key: > > > > It is a nice idea which can be used to optimize both performance > > and memory usage. =20 >=20 > I agree it's a nice idea. I didn't go that way in my draft, because > (i) the optimization is minor, a single chacha_core operation and > very small state, and (2) because it's very algorithm specific, it > doesn't generalize to other AEAD ciphers. I'd be happy to change, if > there is support for this idea. I also consider this optional in my "variant" proposal; I'd be also fine with the current openssh implementation simply using a second key. When encrypting the packet length is still required (see my comments regarding "protocol rethink" above) I think using different nonces in a generic AEAD specification is a good idea (although I don't think the shift by one bit is a good idea. I'd rather shift by 32-bits, requiring a >=3D 8-byte nonce instead of >=3D 5-byte). > Also note that it's straightforward to this based on a pure > RFC5116-style interface to chacha-poly1305, which doesn't output the > additional bytes of the first block: simply run chacha20 one more time > to get the bytes used for length encryption. No less efficient than > using a separate chacha instance, like openssh is doing. Agreed. > > - Changing padding requirements, authentication of the encrypted > > length: > > > > I see no need to change this in the context of a single algorithm. > > Belongs into a more generic protocol redesign. =20 >=20 > I'm afraid some tweaks to the padding requirements are needed even if > you only think of chacha-poly1305, the original padding rules don't > make much sense when the length isn't encrypted in the same way as > the rest of the payload. Sorry :) I considered the EtM padding handling as done in openssh a "standard"; I meant I'd rather avoid further changes in context of a single algorithm: I'd keep the "at least four bytes" and "pad to multiple of min(8, blocksize)" requirements (which results in a minimum packet size of 12 bytes instead of 16 with MtE). > And I think it's desirable to have AEAD ciphers in ssh do things the > same way. It's a bit annoying, because the details aren't terribly > important, but it has to be nailed down, and I have difficulty > finding a way that isn't a bit ugly in one way or the other. I agree that a better AEAD integration is needed, and that it should be done in a consistent way. The question remains: push "chacha20-poly1305" being identical or close to the openssh one or wait for a generic AEAD / "protocol rethink"? Cheers, Stefan From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 27 06:50:13 2016 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE5612D1D9 for ; Wed, 27 Apr 2016 06:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 L0HXnwwxk7NL for ; Wed, 27 Apr 2016 06:50:08 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::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 70F5912D5DF for ; Wed, 27 Apr 2016 06:50:04 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 2578685E96; Wed, 27 Apr 2016 13:50:02 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id F01F685E5C for ; Wed, 27 Apr 2016 13:49:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id B0R_E4wsIiTi for ; Wed, 27 Apr 2016 13:49:57 +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 5121F84C85 for ; Wed, 27 Apr 2016 13:49:56 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id E14EA40028; Wed, 27 Apr 2016 15:49:49 +0200 (CEST) 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 A95BE40014; Wed, 27 Apr 2016 15:49:48 +0200 (CEST) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Wed, 27 Apr 2016 15:49:48 +0200 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: Stefan =?utf-8?Q?B=C3=BChler?= Cc: ietf-ssh@netbsd.org Subject: Re: ChaCha20-Poly1305 for SSH References: <20160420101838.5861b73d@chromobil-cert.local> <20160422125731.56e804dc@chromobil-cert.local> Date: Wed, 27 Apr 2016 15:49:48 +0200 In-Reply-To: <20160422125731.56e804dc@chromobil-cert.local> ("Stefan =?utf-8?Q?B=C3=BChler=22's?= message of "Fri, 22 Apr 2016 12:57:31 +0200") Message-ID: 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 Stefan B=C3=BChler writes: > On Thu, 21 Apr 2016 21:15:55 +0200 > nisse@lysator.liu.se (Niels M=C3=B6ller) wrote: >> I hope you've also seen draft-nisse-secsh-aead-00. I'm replying >> looking for ways to improve that and move forward.=20 > > My feeling is that this document already is the "protocol rethink" (and > not just a "small algorithm family"), That's not my intention. I want it to be general enough to guide specification of other aead schemes, but otherwise keep changes close to minimal. (To really do minimal changes to the ssh protocol, one shouldn't do aead at all, but specify chacha as a cipher, and some mac based on poly1305, and use the old way of applying the mac to the plain text). > Oh my... sorry. I meant Chacha20 of course; DJBs original definition > uses a little-endian 64-bit block-counter and a 64-bit nonce (often the > packet counter). RFC7539 moves the trailing 4 bytes from the block > counter (which are almost always zero - no packet is that big) and > prepends them to the nonce in the interface (but does the same thing > internally) to get the "standard" 12-byte nonce interface. To me, 64 bits sounds like a very reasonable size for both the counter and the nonce. I haven't quite understood why RFC 5116 mandates ("SHOULD") a 12-byte nonce, or its separation into "fixed" and "counter" part.=20 For ssh, it doesn't matter, a 32-bit block counter is large enough, by a large margin. >> I agree it's a nice idea. I didn't go that way in my draft, because >> (i) the optimization is minor, a single chacha_core operation and >> very small state, and (2) because it's very algorithm specific, it >> doesn't generalize to other AEAD ciphers. I'd be happy to change, if >> there is support for this idea. > > I also consider this optional in my "variant" proposal; I'd be also > fine with the current openssh implementation simply using a second key. > > When encrypting the packet length is still required (see my comments > regarding "protocol rethink" above) I think using different nonces in a > generic AEAD specification is a good idea (although I don't think the > shift by one bit is a good idea. I'd rather shift by 32-bits, requiring > a >=3D 8-byte nonce instead of >=3D 5-byte). If we go with the 5116-style AEAD, I guess it would make some sense to describe the distinct-nonce hack using the "fixed | counter"-terminology, with a fixed part being different for length field and the data. But then why not do it the same way for chacha-poly1305? The reason why I ended up proposing the shift-by-one-bit construction was that I think a reasonable AEAD API will have an auto-increment function, incrementing the nonce by one for each message processed. With the shift-by-one bit, the sequence in which nonces are used is simply incrementing, with even ones for length encryption and odd ones for data. With any other formatting, one would need two set_nonce calls per message, or two separate state structs. So that seemed convenient to me, but I guess I'm biased by how my crypto library works. > I'd keep the "at least four bytes" and "pad to > multiple of min(8, blocksize)" requirements (which results in a > minimum packet size of 12 bytes instead of 16 with MtE). Noted (I think some one else expressed a similar opinion). But precesily what is padded changes, with aead, it has to be the data exluding the length field. And I take it chacha should be viewed as a stream cipher and hence pad to 8 bytes, not pad to 64 bytes? > The question remains: push "chacha20-poly1305" being identical or close > to the openssh one or wait for a generic AEAD / "protocol rethink"? My preference would be 1. Do something close to openssh. 2. Specify use of chacha and poly1305 as separate cipher and mac. 3. Wait for ssh version 3, which isn't likely to happen. Regards, /Niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.