1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
|
Return-Path: <forum@leeclagett.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DEB06409
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 24 May 2016 20:24:23 -0400 (EDT)
Date: Tue, 24 May 2016 20:22:50 -0400
From: Lee Clagett <forum@leeclagett.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <bitcoin-dev@lists.linuxfoundation.org>
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.
[...]
>
> </jonas>
>
Lee
|
