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
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9B3FB902
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 May 2016 09:36:29 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from server3 (server3.include7.ch [144.76.194.38])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id EA3D0101
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 May 2016 09:36:27 +0000 (UTC)
Received: by server3 (Postfix, from userid 115)
id 819B92E6017D; Wed, 25 May 2016 11:36:26 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Spam-Level:
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1
autolearn=ham version=3.3.1
Received: from Jonass-MacBook-Pro.local (cable-static-140-182.teleport.ch
[87.102.140.182]) by server3 (Postfix) with ESMTPSA id BEAC62D002BC
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 May 2016 11:36:25 +0200 (CEST)
To: bitcoin-dev@lists.linuxfoundation.org
References: <56F2B51C.8000105@jonasschnelli.ch>
<56FEE39B.3040401@jonasschnelli.ch>
<20160409154038.4c04dd9b@laptop-m1330>
<573C212C.6070604@jonasschnelli.ch>
<20160524202250.01db6f61@laptop-m1330>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <57457218.6060804@jonasschnelli.ch>
Date: Wed, 25 May 2016 11:36:24 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <20160524202250.01db6f61@laptop-m1330>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="DN473J4fxqsHUgGBtCBbfCqjGcrbQ2nHe"
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 09:36:29 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--DN473J4fxqsHUgGBtCBbfCqjGcrbQ2nHe
Content-Type: multipart/mixed; boundary="B08LAIBXFE4TV0JeCjTHRVMG2qKeGwTMU"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <57457218.6060804@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs
References: <56F2B51C.8000105@jonasschnelli.ch>
<56FEE39B.3040401@jonasschnelli.ch> <20160409154038.4c04dd9b@laptop-m1330>
<573C212C.6070604@jonasschnelli.ch> <20160524202250.01db6f61@laptop-m1330>
In-Reply-To: <20160524202250.01db6f61@laptop-m1330>
--B08LAIBXFE4TV0JeCjTHRVMG2qKeGwTMU
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
>> 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.
>=20
> 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.
>=20
> 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").
Okay. Got your point.
The current BIPs assumption is that an encrypted package/message can
contain 1..n bitcoin messages (a single bitcoin message distributed over
multiple encrypted messages/packages was not specified).
But right, this could make sense.
Let me think this through....
> 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 fro=
m
> being tunnelled; the lengths are independent.
TLS/SSH tunneling is already possible with third party software like
stunnel.
Also there is promising projects that would encrypt the traffic "on a
deeper layer" (see CurveCP).
I think what we want is a simple, openssl-independent traffic encryption
built into the core p2p layer.
IMO the risk of screwing up the implementation is moderate.
The implementation is not utterly-complex:
OpenSSH chacha20:
https://github.com/openssh/openssh-portable/blob/0235a5fa67fcac51adb564cb=
a69011a535f86f6b/chacha.c
Chacha20-Poly1305:
https://github.com/openssh/openssh-portable/blob/0235a5fa67fcac51adb564cb=
a69011a535f86f6b/cipher-chachapoly.c
Sure. Before an implementation will be deployed to the endusers it will
require intense cryptoanalysis first.
</jonas>
--B08LAIBXFE4TV0JeCjTHRVMG2qKeGwTMU--
--DN473J4fxqsHUgGBtCBbfCqjGcrbQ2nHe
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJXRXIYAAoJECnUvLZBb1PsnCkP/13tmyamj1c6DeJV89LZbmCa
LSEUPqh08sKiiNxV1y3Tqg97NTLwyz436WUEeLlEEa4Nxvkj3dD3ctGh4wQRMYSD
onobpBUL33oOM02+r3TznlMYPMwXaif+vfOjOcQZnj54XS/PpoVKGf7oDkrEF1Sh
TjiqMe9807gn4Yhg77mTsMTF+H/qjMW+i1Y75OUvcU0C3oPjcSkH+waifggGV9q/
1W6H/6Kw3JY4Ce0j+u2FA2JrLY2Qti56U5bG+hJ3Qn8SVJlXcTWrNL0gPxGLHBop
dVJXYNR0X59OXQg+K6TGvX+Tyf4ErMwN98tzfTD1sWVbso+rfvJxVHQ+2Oi1hOQg
Gg7NX+in082+We3ymFVuT4RC31a6kzXSMV21XKJkzJL5HCuzuOqtwA8cTlmeDaub
y3WBK39wz4fm8J7tayw3TxuuHCySgR4uJVXK/r+eU9Mz7DEJ4AVIxy1Qt52vxjKc
M9vnXAIoOzER/44lldtTaidAG97u1runyMltUNzbmdCLXXqWU+GnIpkemax7B6oP
UFD2Htw+Jx5lMSTYOSW04FyS5W4bMjKS0R66scElcj1SI9nPX8l3MxRPTqzteb34
SH5t6HNKKgIA9rQcOIJiK0WyKRLBsjSvTDhYlDChURdzRUuWNn95tZKEPnP2ma12
Ph4fK5DHk+8KfGYQ+FBE
=Cvl4
-----END PGP SIGNATURE-----
--DN473J4fxqsHUgGBtCBbfCqjGcrbQ2nHe--
|
