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
|
Return-Path: <tomz@freedommail.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E081826C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Mar 2016 20:36:11 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mx-out02.mykolab.com (mx01.mykolab.com [95.128.36.1])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 12BE5198
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Mar 2016 20:36:11 +0000 (UTC)
X-Virus-Scanned: amavisd-new at kolabnow.com
X-Spam-Score: -2.9
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
Received: from mx05.mykolab.com (mx05.mykolab.com [10.20.7.161])
by mx-out02.mykolab.com (Postfix) with ESMTPS id 87C4B60336
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Mar 2016 21:36:07 +0100 (CET)
From: Tom <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Wed, 23 Mar 2016 20:36 +0000
Message-ID: <1983116.UNQS71VxHo@garp>
In-Reply-To: <56F2B51C.8000105@jonasschnelli.ch>
References: <56F2B51C.8000105@jonasschnelli.ch>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 23 Mar 2016 20:37:35 +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 20:36:12 -0000
On Wednesday 23 Mar 2016 16:24:12 Jonas Schnelli via bitcoin-dev wrote:
> Hi
>
> I have just PRed a draft version of two BIPs I recently wrote.
> https://github.com/bitcoin/bips/pull/362
I suggest running a spellchecker ;)
Some questions;
* why would you not allow encryption on non-pre-approved connections?
* we just removed (ssl) encryption from the JSON interface, how do you suggest
this encryption to be implemented without openSSL?
* What is the reason for using the p2p code to connect a wallet to a node?
I suggest using one of the other connection methods to connect to the node.
This avoids a change in the bitcoin protocol for a very specific usecase.
* Why do you want to do a per-message encryption (wrapping the original)?
Smaller messages that contain predictable content and are able to be matched
to the unencrypted versions on the wire send to other nodes will open this
scheme up to various old statistical attacks.
> Responding peers must ignore (banning would lead to fingerprinting) the
requesting peer after 5 unsuccessfully authentication tries to avoid resource
attacks.
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?
> To ensure that no message was dropped or blocked, the complete communication
must be hashed (sha256). Both peers keep the SHA256 context of the encryption
session. The complete <code>enc</code> message (leaving out the hash itself)
must be added to the hash-context by both parties. Before sending a
<code>enc</code> command, the sha256 context will be copied and finalized.
You write "the complete communication must be hashed" and every message has a
hash of the state until it is at that point.
I think you need to explain how that works specifically.
|
