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
161
162
|
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 F2AEA74
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Mar 2016 09:01:41 +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 2BBA4EB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Mar 2016 09:01:41 +0000 (UTC)
Received: by server3 (Postfix, from userid 115)
id 423A22E200F6; Sat, 26 Mar 2016 10:01:40 +0100 (CET)
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 7E3582D00182
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Mar 2016 10:01:39 +0100 (CET)
To: bitcoin-dev@lists.linuxfoundation.org
References: <56F2B51C.8000105@jonasschnelli.ch> <2590065.B4dTBeyc1A@garp>
<56F586B4.8020507@jonasschnelli.ch> <4517402.JLxTDjem5X@garp>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <56F64FF0.7060706@jonasschnelli.ch>
Date: Sat, 26 Mar 2016 10:01:36 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <4517402.JLxTDjem5X@garp>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="uirTOEHL6u793p52WGICDQ0DUom0bjkte"
X-Mailman-Approved-At: Sat, 26 Mar 2016 09:41:37 +0000
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 Development 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: Sat, 26 Mar 2016 09:01:42 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--uirTOEHL6u793p52WGICDQ0DUom0bjkte
Content-Type: multipart/mixed; boundary="KkoBEibVi0MVj6xuEVO6ESSE3G68I4bFC"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <56F64FF0.7060706@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs
References: <56F2B51C.8000105@jonasschnelli.ch> <2590065.B4dTBeyc1A@garp>
<56F586B4.8020507@jonasschnelli.ch> <4517402.JLxTDjem5X@garp>
In-Reply-To: <4517402.JLxTDjem5X@garp>
--KkoBEibVi0MVj6xuEVO6ESSE3G68I4bFC
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
> I guess my question didn't get across.=20
>=20
> Why would you want to make your usecase do connections over the peer2pe=
er=20
> (net.cpp) connection at all?
First, because there _are_ a hight amount of SPV wallets in the field.
SPV wallets are "dumb-clients" with only a tiny value for the bitcoin
network (they don't validate, they don't relay). They already are
decoupled wallets. We need solution that offers higher privacy and
higher traffic analysis resistance.
Using the p2p channel for communication between full validation peers
and wallet-only-peers makes sense IMO because wallet-only-peers can
slowly validate the chain and create a UTXO set in the background (could
take a couple of weeks) or solve other purposes that increases the
security and/or serving something back to the bitcoin network.
Sure, you can always use client/server wallets (Coinbase / Copay, etc.)
that offers SSL.
But I strongly recommend to improve the communication and interface
possibilities between wallet-nodes (SPV) and full-validation-nodes.
Otherwise we will very likely see centralization regarding end-user
wallets (with all the large risks of disrupting the community in case of
attacks/thefts, etc.).
_If we think Bitcoin should scale, we also need to scale and improve at
the point where users enter the network and start using Bitcoin._
> Mixing messages that are being sent to everyone and encrypted messages =
is=20
> asking for trouble.
> Making your private connection out-of-band would work much better.
The current encryption BIP requires to encrypt the complete traffic.
Having an option to do analysis resistant communication with a remote
peer within the protocol itself is something that is very valuable IMO.
>>> Also, you didn't actually address the attack-vector.
>>
>> Which attack-vector?
>=20
> The statistical attack I mentioned earlier. Which comes from knowing w=
hich=20
> plain text messages are being sent over the encrypted channel, So as lo=
ng as=20
> you keep saying you want to encrypt data that identical copies of are b=
eing=20
> sent to other nodes at practically the same time, you will keep being=20
> vulnerable to that.
The encryption BIP recommends Chacha20-Poly1305 as encryption AEAD. This
is a very broad used encryption scheme (Google uses it to connect
Android phones with their cloud services).
Completely avoiding side channel on data analysis would probably require
extremely inefficient constant time encrypted datastreams.
Also, the BIP allows combining of multiple plaintext message in one
encrypted message.
Additionally we could extend the enc. BIP by allowing random padding of
encrypted messages or other techniques to reduce side channel analysis.
</jonas>
--KkoBEibVi0MVj6xuEVO6ESSE3G68I4bFC--
--uirTOEHL6u793p52WGICDQ0DUom0bjkte
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
iQIcBAEBCAAGBQJW9k/wAAoJECnUvLZBb1Psg/sP/052T7OPZqSfI8wWQxDDR5Hk
z0mp4ASjY7qE1ePcdBpXsntPeAvhEkxLdZBb4/9MQFyMjx5pa0qu342Nwx6rYOrt
PDb8hWLUD4EMLgvQgGmB2fpAZmcr3CDvoRHZrbbicG07sFMBooxDzxlnEPQZNp14
RziMhrXww1oCCU0nYuXUJ/uHLWXCQIOP5B6ZcaCoL4atq76dSn2wE6TSdqi5T5KK
l1KMzCMbZ710rGzJ0JKRowSYqx2E2Z9FCceikk0nYYUZGNuT50bhYI5z1T7PLZ/H
iJmnzSwOs0PCVtuKDyHFgY30AF1lCzLxdALDohRf4EKMoTjJeYObshnN5rL5srYJ
kJxBEm0mskpypx/lQbIjMvuGcrJ6waMiG7wtM2VROrBt8jeXPxtBHV52YNaBX6GZ
C9LRckx3lcoEGsoKH3hN1McE+DrKjZxySAmzKBN086XrIGy5vIDpwj+1T2vILkCL
0kDbEsen9Zd9Ldy+PyENI7YDOhCU1OqQUKcVkjF6LUFk1dxTdi5yvrNXkPGD3hTU
UOO0O8atpHLKzGYz7OXYFtSgMtmBKElwdYImHaMG4WF18lLulNPYqfzXdpqfv6RD
aFIhzdjbg1kxI4/QHTSjMnQCR5nnrCmyrsPoJ4stcDT4Y2Ao04oxRBzLyJ5HfTD6
yL4kzQ8iauQG5lRPTVXH
=nkkG
-----END PGP SIGNATURE-----
--uirTOEHL6u793p52WGICDQ0DUom0bjkte--
|
