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
|
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 A9F3769
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Mar 2016 11:58:17 +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 D3FA6EB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Mar 2016 11:58:16 +0000 (UTC)
Received: by server3 (Postfix, from userid 115)
id 66F342D00B2B; Sun, 27 Mar 2016 13:58:15 +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 9032D2D00112
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Mar 2016 13:58:14 +0200 (CEST)
To: bitcoin-dev@lists.linuxfoundation.org
References: <56F2B51C.8000105@jonasschnelli.ch> <2590065.B4dTBeyc1A@garp>
<56F586B4.8020507@jonasschnelli.ch> <4517402.JLxTDjem5X@garp>
<CAH+Axy7cyZXzAHE7bfGxyMF8oxy=hpOW9nFd5KiLnVab3b=qCA@mail.gmail.com>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <56F7CAD3.9080809@jonasschnelli.ch>
Date: Sun, 27 Mar 2016 13:58:11 +0200
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: <CAH+Axy7cyZXzAHE7bfGxyMF8oxy=hpOW9nFd5KiLnVab3b=qCA@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="1I4d5Sb8IWHl33fOjRLdVvCWsH3CoeWT7"
X-Mailman-Approved-At: Sun, 27 Mar 2016 12:48:56 +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: Sun, 27 Mar 2016 11:58:17 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--1I4d5Sb8IWHl33fOjRLdVvCWsH3CoeWT7
Content-Type: multipart/mixed; boundary="gaeTNd8o7qcTN4b6kbOuXkvRJfnlNnKKD"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <56F7CAD3.9080809@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>
<CAH+Axy7cyZXzAHE7bfGxyMF8oxy=hpOW9nFd5KiLnVab3b=qCA@mail.gmail.com>
In-Reply-To: <CAH+Axy7cyZXzAHE7bfGxyMF8oxy=hpOW9nFd5KiLnVab3b=qCA@mail.gmail.com>
--gaeTNd8o7qcTN4b6kbOuXkvRJfnlNnKKD
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
> I guess my question didn't get across.
>=20
> Why would you want to make your usecase do connections over the
> peer2peer
> (net.cpp) connection at all?
>=20
> Mixing messages that are being sent to everyone and encrypted
> messages is
> asking for trouble.
> Making your private connection out-of-band would work much better.
>=20
>=20
> I agree doing it out-of-band is the easiest solution for people who nee=
d
> this privacy right now, but I do like the idea of adding this feature a=
s
> the number of SPV wallets is going to increase. I think the best way to=
> organize things would be to give encrypted messages their own port
> number, similar to how http vs. https works.
I'm not sure if different ports would make sense. I can't see a benefit
(happy if someone can convince me).
How would this affect p2p address management (address relay)? Wouldn't
this require to extend the current address message to support two port
numbers?
> We don't want two networks to develop, separated by which nodes support=
> encryption and which don't, so ideally nodes would rebroadcast messages=
> they receive on both (encrypted and non-encrypted) channels. This would=
> essentially double the required bandwidth of the network, which is
> something to think about.
It can be the same "p2p network". The only difference would be, that
once two peers has negotiated encryption, the whole traffic between
_these two peers_, and _only_ these two pears, would be encrypted (would
_not_ affect traffic to/from other peers).
A simplified example:
1. Peer Alice connects to peer Bob
2. Alice asks Bob: "lets do encrypted communication, here is my session
pubkey"
3. Bob also supports encryption and answers "Yes, let's do this, here is
my session pubkey"
4. Alice tells Bob (encrypted now): "Perfect. Here I prove that I'm
Alice by signing the session ID with my identity pubkey"
5. Bob checks his "authorized-peers" database and look-up Alices pubkey
and verifies the signatures.
6. Bob tells Alice: "Good! I trust you now Alice, here is my identity
pubkey with a signature of our session-ID"
7. Alice looks up Bobs pubkey in her "known-peers" database and verifies
the signature.
8. Alice response to bob: "Perfect. Indeed, you are Bob!"
---
At this point, the communication is encrypted and the identities has
been verified (MITM protection).
(simplified negotiation [only one-way, missing dh explanation, missing
KDF, session-ID, cipher suite nego., missing re-keying, etc.])
</jonas>
--gaeTNd8o7qcTN4b6kbOuXkvRJfnlNnKKD--
--1I4d5Sb8IWHl33fOjRLdVvCWsH3CoeWT7
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
iQIcBAEBCAAGBQJW98rTAAoJECnUvLZBb1PsS7wP/3Tch2oLUcbYRZp2N212botL
kfLwZL+FeSHlqz+hK4TPFkd2rGMoW8odbiK8SbQjK9+k+ynQg2KT25BjKSPxyXN4
A1Pknz+qRpx/s0fApG3WfFFmLXi5KORBiDjhGyXIXGok0+cUoOBr+QNlscLBl1lD
vlgktlGxQxbz9JsZho9XGUfAxFgTE0gF5j127bDbksmn2nxYDrDu9d+mrt5X0XMj
9/XBqfwr465Njoy5nXgntIB6s2l1N0fOcsm+vLOYDAo1h9dcuAKDrg7JM+CAdsFO
m9+fspeTqg64TFTw8hbK8d61h3tiM1WB6+y5j3W5mX0ZQuxH1jz5RDNKlJh35r6X
1sk/8kq1BkommpH8pQBz5O5oFS0DWHJtuDjXJm+Cm9pbvsrQOVnag3U7uMjwpSYm
MBVM9vk9ZhFMMPH5Vb+NJUbzDklbEDPx2uEn5oSkMq2hC47d7BgNSmoQCG6KWoyj
4j4X7ZWf7k2AOa6L+FuHiJGMuLA9sj5tpRLgfAwhqWEp6G1pQ2ovWYLNLDKgywH9
Yfqy+CSugOBP3x1f/2dNIrPpkZQ5L0L0AWfN2TDlMScedzzbuT3K3zDZactHXN+o
iQv0G0YXvfUzSeRKd82At97YPWgOWPa+rz4fd3xNHxGL5vb0gN8yzm1dWTP8NFqF
l0vrFudh8W5+WcTq++Ru
=u0JB
-----END PGP SIGNATURE-----
--1I4d5Sb8IWHl33fOjRLdVvCWsH3CoeWT7--
|
