Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9E597DCA for ; Mon, 17 Jun 2019 17:13:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EFBDA7DB for ; Mon, 17 Jun 2019 17:13:34 +0000 (UTC) Received: by mail-lj1-f181.google.com with SMTP id i21so10068455ljj.3 for ; Mon, 17 Jun 2019 10:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VHVplfFQ7defGOy8Du8Y8IIhQCC08xhB+9DY7zlQUrw=; b=E0JUp/0JKq7CHgF561ir9hkdwxbAmggzPxosvHvIjbSsc5ty1pE8PKGloWkV9zvV69 OVQs6b4s5T015Xf7dEezeFaBkUsdjefXJLO4SvAjQjtSq3+gQxSspGr3csIcSSbtnKIM ihe514FGErAnjem3g3HNAh7lswzAwML/4+ZnkzxOqAu3dy6L/i4iJ/ro8vDZLPf2m1x7 RjgwvbZ9ZHHygaYLZvlFSna5NIhBPjvPRI36I6n4XQ8XJX9dc7mEsUW+coBKpZboFrAZ yLrHWnqKAoh08mY4JhsX9UFEQur66OS2f0MXWCYtyHrmLGr7GF778wWTZPJklTXMEN6L 5WZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VHVplfFQ7defGOy8Du8Y8IIhQCC08xhB+9DY7zlQUrw=; b=uRBlhTy/W462bkGbCee1mIXWyUuFbgE5WoKK/1zRElfg1EBaQ8s39knaJNorteO46o cr3vj8XmZFkhRhwvKn8GMWjicT/TeEPTq8d7E8yr3azvfC8+q41CILLYZ9+/e8Wcg3Wg B3dUhlqANycReEe/aKESuazMIs76K5+DlBYtZz2PjZB3AGaqLcAR0HzpJ8O51ZHTy/Ji 6d2Q4rH/wlDo0OUyyWWrvA2STAcNoeh+z3umLXMdzBAeAOgrDOIShdjj/FiMuUT5tLIe Xfb+hsyv0E5ebutLxuHCgzTRSMm/XFPU0lcqYFLcz8JJuDstcgbdxQEhKwny1KzmNDJt OwZw== X-Gm-Message-State: APjAAAXoq3C8UbdUZro2uEI+3xnJDGc018MopSa+jH8m4z26DthxDO8B H+kMrn8pZKnsaAG3hOez7huxmmOWpqNe/Fy0vH0= X-Google-Smtp-Source: APXvYqz80RQJgh6TT0nbJbGpH4cQd6S2fdMq0BobHpbspn7WXXymV9ZA8O2dBAvX8XpitfZzLzUiGsGKv6KObHf5J/U= X-Received: by 2002:a2e:29c4:: with SMTP id p65mr31788335ljp.141.1560791612848; Mon, 17 Jun 2019 10:13:32 -0700 (PDT) MIME-Version: 1.0 References: <76890B69-2004-41C4-B4E7-0C5D070142C3@jonasschnelli.ch> In-Reply-To: <76890B69-2004-41C4-B4E7-0C5D070142C3@jonasschnelli.ch> From: Elichai Turkel Date: Mon, 17 Jun 2019 13:13:05 -0400 Message-ID: To: Jonas Schnelli Content-Type: multipart/alternative; boundary="000000000000a79b41058b881d9b" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 18 Jun 2019 06:36:30 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 17:13:35 -0000 --000000000000a79b41058b881d9b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, I just couldn't find where is the message sequence number comes from. So if it's max 1GB and it's an incremental counter that cannot be reseted without a rekeying than it's perfectly fine :). Thanks for the answer! On Mon, Jun 17, 2019 at 12:20 PM Jonas Schnelli wrote: > Hi Elichai > > > About the nonce being 64bit. (rfc7539 changed it to 96bit, which djb > later calls xchacha) > > > > You suggest that we use the "message sequence number" as the nonce for > Chacha20, Is this number randomly generate or is this a counter? > > And could it be reseted without rekeying? > > The in BIP324 (v2 message transport protocol) proposed AEAD, > ChaCha20Poly1305@Bitcoin [1], uses a =E2=80=9Emessage sequence number=E2= =80=9C. There is > no such thing as random nonce described in the BIP (hence the term > =E2=80=9Esequence number=E2=80=9C). The message sequence number starts wi= th 0 and the max > traffic before a rekey must occur is 1GB. A nonce/key reuse is conceptual= ly > impossible (of course implementations could screw up at this point). > > Using XChaCha20 with the possibility of a random nonce could be done, but > I don=E2=80=99t see a reason to use it in our case since the usage of a s= equence > number as nonce seems perfectly save. > > [1] > https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#ch= acha20-poly1305bitcoin-cipher-suite > --=20 PGP: 5607C93B5F86650C --000000000000a79b41058b881d9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks,
I just couldn't find where= is the message sequence number comes from.
So if it's max 1GB and i= t's an incremental counter that cannot be reseted without a rekeying th= an it's perfectly fine :).

Thanks for the answer!

On Mon, Jun 17,= 2019 at 12:20 PM Jonas Schnelli <dev@jonasschnelli.ch> wrote:
Hi Elichai

> About the nonce being 64bit. (rfc7539 changed it to 96bit, which djb l= ater calls xchacha)
>
> You suggest that we use the "message sequence number" as the= nonce for Chacha20, Is this number randomly generate or is this a counter?=
> And could it be reseted without rekeying?

The in BIP324 (v2 message transport protocol) proposed AEAD, ChaCha20Poly13= 05@Bitcoin [1], uses a =E2=80=9Emessage sequence number=E2=80=9C. There is = no such thing as random nonce described in the BIP (hence the term =E2=80= =9Esequence number=E2=80=9C). The message sequence number starts with 0 and= the max traffic before a rekey must occur is 1GB. A nonce/key reuse is con= ceptually impossible (of course implementations could screw up at this poin= t).

Using XChaCha20 with the possibility of a random nonce could be done, but I= don=E2=80=99t see a reason to use it in our case since the usage of a sequ= ence number as nonce seems perfectly save.

[1] https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c5148632= 5587c52#chacha20-poly1305bitcoin-cipher-suite


--
PGP: 5607C93B5F86650C
--000000000000a79b41058b881d9b--