From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DEB06409 for ; Wed, 25 May 2016 00:33:54 +0000 (UTC) X-Greylist: delayed 00:09:23 by SQLgrey-1.7.6 Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D996D1D2 for ; Wed, 25 May 2016 00:33:52 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id A95C81F2C1 for ; Tue, 24 May 2016 20:24:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=bBKuDncOZ3z1 LGNwzcOHIcB/TQA=; b=bLD+b0TY2LxCGGgojiu6CG0bQLxpQbd08ByZyJmTu7LQ GjATR1n7zhVBKxc0b81iyvqH0W1kW9HymwBi4J5QbwQSuC/mf2FYJ4AJmtNUmmmn NWsVcOzf4WG3gjcqJQHrwmdglB3C/ID7NxkUVVz+ZQoVXQaiDjiLm5y+vkfqif4= Received: from pb-smtp1. (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id A2C6A1F2C0 for ; Tue, 24 May 2016 20:24:24 -0400 (EDT) Received: from laptop-m1330 (unknown [173.30.126.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id D0DE51F2BF for ; Tue, 24 May 2016 20:24:23 -0400 (EDT) Date: Tue, 24 May 2016 20:22:50 -0400 From: Lee Clagett To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20160524202250.01db6f61@laptop-m1330> In-Reply-To: <573C212C.6070604@jonasschnelli.ch> References: <56F2B51C.8000105@jonasschnelli.ch> <56FEE39B.3040401@jonasschnelli.ch> <20160409154038.4c04dd9b@laptop-m1330> <573C212C.6070604@jonasschnelli.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 083A27B4-220F-11E6-A5D5-9A9645017442-92142693!pb-smtp1.pobox.com X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs 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: Wed, 25 May 2016 00:33:55 -0000 On Wed, 18 May 2016 10:00:44 +0200 Jonas Schnelli via bitcoin-dev wrote: > Hi Lee > > Thank you very much for the valuable input. > I'm still processing your feedback.... [...] > > Why have a fixed MAC length? I think the MAC length should be > > inferred from the cipher + authentication mode. And the Poly1305 > > tag is 16 bytes. > > > > *Unauthenticated Buffering* > > Implementations are unlikely to (i.e. should not) process the > > payload until authentication succeeds. Since the length field is 4 > > bytes, this means an implementation may have to buffer up to 4 GiB > > of data _per connection_ before it can authenticate the length > > field. If the outter length field were reduced to 2 or 3 bytes, the > > unauthenticated buffering requirements drop to 64 KiB and 16 MiB > > respectively. Inner messages already have their own length, so they > > can span multiple encrypted blocks without other changes. This will > > increase the bandwidth requirements when the size of a single > > message exceeds 64 KiB or 16 MiB, since it will require multiple > > authentication tags for that message. I think an additional 16 > > bytes per 16 MiB seems like a good tradeoff. > > > > Good point. > I have mentioned this now in the BIP but I think the BIP should allow > message > 16 MiB. > I leave the max. message length up to the implementation while keeping > the 4 byte length on the protocol level. I expect the implementation defined max size to work (SSH 2.0 does this after all), but I want to make sure my suggestion is understood completely. There is a length field for the encrypted data, and length field(s) inside of the encrypted data to indicate the length of the plaintext Bitcoin messages. I am suggesting that the outter (encrypted) length field be reduced, which will _not limit_ the length of Bitcoin messages. For example, if a 1 GiB Bitcoin message needed to be sent and the encrypted length field was 3 bytes - the sender is forced to send a minimum of 64 MACs for this message. The tradeoff is allowing the receiver to detect malformed data sooner and have a lower max buffering window **against** slightly higher bandwidth and CPU requirements due to the additional headers+MACs (the CPU requirements should primarily be in "finalizing each Poly1305"). An alternative way to think about the suggestion is tunnelling Bitcoin messages over TLS or SSH. TLS 1.2 has a 2-byte length field and SSH 2.0 a 4-byte length field, but neither prevents larger Bitcoin messages from being tunnelled; the lengths are independent. [...] > > > Lee