summaryrefslogtreecommitdiff
path: root/bb/6dac1965f54cd3cdd4b6ac3c1ff5a019e2a9a7
blob: f01189a87ab96dc1c11fbe034d049ffec76abbe8 (plain)
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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gubatron@gmail.com>) id 1XJmkW-0002Oh-TE
	for bitcoin-development@lists.sourceforge.net;
	Tue, 19 Aug 2014 16:59:08 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.180 as permitted sender)
	client-ip=209.85.216.180; envelope-from=gubatron@gmail.com;
	helo=mail-qc0-f180.google.com; 
Received: from mail-qc0-f180.google.com ([209.85.216.180])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XJmkV-0006UG-H4
	for bitcoin-development@lists.sourceforge.net;
	Tue, 19 Aug 2014 16:59:08 +0000
Received: by mail-qc0-f180.google.com with SMTP id l6so6436293qcy.25
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 19 Aug 2014 09:59:02 -0700 (PDT)
X-Received: by 10.140.34.164 with SMTP id l33mr17911551qgl.72.1408467541748;
	Tue, 19 Aug 2014 09:59:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.86.37 with HTTP; Tue, 19 Aug 2014 09:58:41 -0700 (PDT)
In-Reply-To: <CAAS2fgTF6424+FfzaL=+iaio2zu_uM_74yKohi7T3dtz=J9CjA@mail.gmail.com>
References: <CA+8=xuJ+YDTNjyDW7DvP8KPN_nrFWpE68HvLw6EokFa-B-QGKw@mail.gmail.com>
	<CA+8=xuKRyO1=bu7cgNGHvtAeqgKBxjTH2uUkb61GdCuEQWEu5A@mail.gmail.com>
	<0C0EF7F9-DBBA-4872-897D-63CFA3853726@ricmoo.com>
	<CA+8=xu+KWSF6XYgH-_t87na6M6UOD0CM1su8sizxn5a4b0_Xrw@mail.gmail.com>
	<33D4B2E3-DBF0-444E-B76A-765C4C17E964@ricmoo.com>
	<53F37635.5070807@riseup.net>
	<CAAS2fgTF6424+FfzaL=+iaio2zu_uM_74yKohi7T3dtz=J9CjA@mail.gmail.com>
From: Angel Leon <gubatron@gmail.com>
Date: Tue, 19 Aug 2014 12:58:41 -0400
Message-ID: <CADZB0_YfNQQstWsFt2+efYQNEhQ6ig8GD+hmbKBW6reZwEqOuQ@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c1002480f34e0500fe6786
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(gubatron[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1XJmkV-0006UG-H4
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
	Justus Ranvier <justusranvier@riseup.net>
Subject: Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 16:59:09 -0000

--001a11c1002480f34e0500fe6786
Content-Type: text/plain; charset=UTF-8

"I suggest that Bitcoin Core should generate a public/private key pair and
share the public one with peers."

I've not read the p2p protocol of Bitcoin core, but I suppose the initial
handshake between 2 peers would be the ideal place to exchange a public
keys.

would it make sense to generate a new random pair of keys per each peer you
connect to?
then each subsequent message to every peer gets encrypted differently,
keeping each conversation isolated from each other encryption-speaking.

These keys would have nothing to do with your wallet, they're just to
encrypt any further communication between peers post-handshake. Would that
be of any use to "This could provide privacy and integrity but not
autentication."?

http://twitter.com/gubatron


On Tue, Aug 19, 2014 at 12:38 PM, Gregory Maxwell <gmaxwell@gmail.com>
wrote:

> On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier
> <justusranvier@riseup.net> wrote:
> > If that's not acceptable, even using TLS with self-signed certificates
> > would be an improvement.
>
> TLS is a huge complex attack surface, any use of it requires an
> additional dependency with a large amount of difficult to audit code.
> TLS is trivially DOS attacked and every major/widely used TLS
> implementation has had multiple memory disclosure or remote execution
> vulnerabilities even in just the last several years.
>
> We've dodged several emergency scale vulnerabilities by not having TLS.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--001a11c1002480f34e0500fe6786
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&quot;<span style=3D"font-family:arial,sans-serif;font-siz=
e:13px">I suggest that Bitcoin Core should generate a public/private key pa=
ir and share the public one with peers.&quot;<br><br>I&#39;ve not read the =
p2p protocol of Bitcoin core, but I suppose the initial handshake between 2=
 peers would be the ideal place to exchange a public keys.<br>

<br>would it make sense to generate a new random pair of keys per each peer=
 you connect to?<br>then each subsequent message to every peer gets encrypt=
ed differently, keeping each conversation isolated from each other encrypti=
on-speaking.<br>

<br>These keys would have nothing to do with your wallet, they&#39;re just =
to encrypt any further communication between peers post-handshake. Would th=
at be of any use to &quot;</span><span style=3D"font-family:arial,sans-seri=
f;font-size:13px">This could provide privacy and integrity but not autentic=
ation.&quot;</span><span style=3D"font-family:arial,sans-serif;font-size:13=
px">?</span></div>

<div class=3D"gmail_extra"><br clear=3D"all"><div><a href=3D"http://twitter=
.com/gubatron" target=3D"_blank">http://twitter.com/gubatron</a><br></div>
<br><br><div class=3D"gmail_quote">On Tue, Aug 19, 2014 at 12:38 PM, Gregor=
y Maxwell <span dir=3D"ltr">&lt;<a href=3D"mailto:gmaxwell@gmail.com" targe=
t=3D"_blank">gmaxwell@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div class=3D"">On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier<br>
&lt;<a href=3D"mailto:justusranvier@riseup.net">justusranvier@riseup.net</a=
>&gt; wrote:<br>
&gt; If that&#39;s not acceptable, even using TLS with self-signed certific=
ates<br>
&gt; would be an improvement.<br>
<br>
</div>TLS is a huge complex attack surface, any use of it requires an<br>
additional dependency with a large amount of difficult to audit code.<br>
TLS is trivially DOS attacked and every major/widely used TLS<br>
implementation has had multiple memory disclosure or remote execution<br>
vulnerabilities even in just the last several years.<br>
<br>
We&#39;ve dodged several emergency scale vulnerabilities by not having TLS.=
<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>

--001a11c1002480f34e0500fe6786--