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
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 89B4392
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Mar 2016 21:40:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com
[209.85.192.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 043B1155
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Mar 2016 21:40:45 +0000 (UTC)
Received: by mail-pf0-f173.google.com with SMTP id 4so40333881pfd.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Mar 2016 14:40:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=message-id:date:from:user-agent:mime-version:to:subject:references
:in-reply-to; bh=YCcJeFS3TWJ5EB6LzfDqrJiPDIj/hFzHJnTY+aEWYzM=;
b=JbKUGOu/hwakwJ47GxFWV6ZaY0irmY0ETHB0GdlUQKtFHnE0TMWFtn3vN6rbe8FKkh
UjW0J7quVbYne58czQ3QocqdYhSjV5rxwS/3zUPIWa9iHyjgX+hz/j7QOtYv4MxkIy6Y
3QHWxrxlqXp+BOBSERRlM/UeYRYo6nFEPBxFLlS38Jtas1g7Xgh1Ir47SewDE87asgTD
LprNbUYL4NzJxvlLl13k39DHjRFawgtZ6nD9zWPGmjjEf7qMKawXfExAcnOeTB4TfSQY
/YW+y/2eQFnRTw+SABsFgEw8wBdNFYjMrqzH8aYzPAkOHhsR4tg4vLpfGvPPGnbRxDv7
0//g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:subject:references:in-reply-to;
bh=YCcJeFS3TWJ5EB6LzfDqrJiPDIj/hFzHJnTY+aEWYzM=;
b=hfKlItHmF0RmCJj+Ii4RPLlt2Pqom/r9qhUFRewHCrBNPa9qAt05uy+kp1nXuikEfu
D20uPN1qQhMqKj8lbOYhruY2oj36QQqXTxO8oEv1E8lw6iZ9g9BS4gvLvjBg2xvGfdX/
eGdd9LQ5eeRliAwF14bzXj8W7tiX0CP1kHiXVvhf5/JOX/yxgZ/PeO5T/Kx85SVqcWfV
t/nNqIQxZa7uRHqCYbp+zCHRmM71DGhJbFmTfOXodcG4fiGBnshXkOvhEYdp/aIWzmcx
5u1dJ4HiVLM14vixXrr/GKqV6KzMc0e1HTY0pxv/6tXQTZOn17/a/QDjubkdjtXewEQU
nteg==
X-Gm-Message-State: AD7BkJLiZJuHlbc/pE4RRANifpQnupyR252sVqmjSzkEKHVR/fWDshMRZ7E8flZ78CWsFw==
X-Received: by 10.98.76.194 with SMTP id e63mr7553592pfj.89.1458769245624;
Wed, 23 Mar 2016 14:40:45 -0700 (PDT)
Received: from ?IPv6:2601:600:9001:8060:3846:59ef:850d:be23?
([2601:600:9001:8060:3846:59ef:850d:be23])
by smtp.googlemail.com with ESMTPSA id
k88sm6325593pfj.0.2016.03.23.14.40.44
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 23 Mar 2016 14:40:44 -0700 (PDT)
Message-ID: <56F30D62.4090409@voskuil.org>
Date: Wed, 23 Mar 2016 14:40:50 -0700
From: Eric Voskuil <eric@voskuil.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Tom <tomz@freedommail.ch>, bitcoin-dev@lists.linuxfoundation.org
References: <56F2B51C.8000105@jonasschnelli.ch> <1983116.UNQS71VxHo@garp>
In-Reply-To: <1983116.UNQS71VxHo@garp>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="IMtfsljsmCuJiOdpeOw5OeuUdeQEdpAHV"
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,RCVD_IN_DNSWL_LOW 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: Thu, 24 Mar 2016 00:40:40 +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: Wed, 23 Mar 2016 21:40:46 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--IMtfsljsmCuJiOdpeOw5OeuUdeQEdpAHV
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 03/23/2016 01:36 PM, Tom via bitcoin-dev wrote:
> On Wednesday 23 Mar 2016 16:24:12 Jonas Schnelli via bitcoin-dev wrote:=
> * why would you not allow encryption on non-pre-approved connections?
Agree
> * we just removed (ssl) encryption from the JSON interface, how do you =
suggest=20
> this encryption to be implemented without openSSL?
CurveCP
> * What is the reason for using the p2p code to connect a wallet to a no=
de?
> I suggest using one of the other connection methods to connect to the n=
ode.=20
> This avoids a change in the bitcoin protocol for a very specific usecas=
e.
Agree, P2P and client-server protocols are distinct use-cases. Missing
this distinction is the root cause of problems with the bloom filters
feature.
> * Why do you want to do a per-message encryption (wrapping the original=
)?=20
> Smaller messages that contain predictable content and are able to be ma=
tched=20
> to the unencrypted versions on the wire send to other nodes will open t=
his=20
> scheme up to various old statistical attacks.
Privacy cannot currently be achieved unless the server is trusted. In
most wallet scenarios that's not a reasonable assumption unless one
controls the full node. So this is only useful in the case where the
wallet is trusting a remote server, and as you point out - message
encryption is weak in this case. In a trustless server scenario
encryption would be unnecessary overhead.
>> Responding peers must ignore (banning would lead to fingerprinting) th=
e=20
> requesting peer after 5 unsuccessfully authentication tries to avoid re=
source=20
> attacks.
>=20
> Any implementation of that kind would itself again be open to resource =
> attacks.
> Why 5? Do you want to allow a node to make a typo?
Agree, denial of service protection can and should be much more flexible
than this. It's not necessary to incorporate DoS protection into a
protocol. I think maybe this stems from the ill-advised attempt at
messaging reliability.
>> To ensure that no message was dropped or blocked, the complete communi=
cation=20
> must be hashed (sha256). Both peers keep the SHA256 context of the encr=
yption=20
> session. The complete <code>enc</code> message (leaving out the hash it=
self)=20
> must be added to the hash-context by both parties. Before sending a=20
> <code>enc</code> command, the sha256 context will be copied and finaliz=
ed.
>=20
> You write "the complete communication must be hashed" and every message=
has a=20
> hash of the state until it is at that point.
> I think you need to explain how that works specifically.
Also, this gets into the area of messaging reliability. This is
certainly not something I would recommend for a P2P protocol optimized
for maintaining a cache of public data.
e
--IMtfsljsmCuJiOdpeOw5OeuUdeQEdpAHV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCAAGBQJW8w1iAAoJEDzYwH8LXOFOC4oH/29fZErxnsOsGBGroyQSwab3
2uBpl4p9ZdXk2gImWUWf7EwsHEoblCjdW62Z1/zRFdCPVj1r9VYNeupgv09tg38E
OgiZgoxZnbmOjfK5VMU5qqX96v31/UOYmlbyYh2AZ1+3MVk1JK5RpamIp8roff2U
uVZ9UBHEUwguyu4xUEShnevmWw7MWMrRPSHQlfsMnnGGis6sU45yaue5SDF+6XMZ
k0lTkM5iptC71V+hOhvo9sK3QPz9Ty2wodOfHbbFDfJEqzCPcWdgulXx558fq5kE
B3TTyLnkMrVe6R+U9Fa5XMmatII9eTUTu69ES0KjzsZvRW9gS1q5SCQFwPq9Fiw=
=qHrZ
-----END PGP SIGNATURE-----
--IMtfsljsmCuJiOdpeOw5OeuUdeQEdpAHV--
|
