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
|
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 895847D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Mar 2016 10:36:34 +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 7797F106
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Mar 2016 10:36:33 +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 431F561421
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Mar 2016 11:36:30 +0100 (CET)
From: Tom <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Fri, 25 Mar 2016 10:36:28 +0000
Message-ID: <2590065.B4dTBeyc1A@garp>
In-Reply-To: <56F310D6.2070002@jonasschnelli.ch>
References: <56F2B51C.8000105@jonasschnelli.ch> <1983116.UNQS71VxHo@garp>
<56F310D6.2070002@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: Fri, 25 Mar 2016 17:30:29 +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: Fri, 25 Mar 2016 10:36:34 -0000
On Wednesday 23 Mar 2016 22:55:34 Jonas Schnelli via bitcoin-dev wrote:
> >> I have just PRed a draft version of two BIPs I recently wrote.
> > * why would you not allow encryption on non-pre-approved connections?
>
> The encryption should be optional.
> The proposed authentication scheme does take care of the
> identity-management and therefor prevent MITM attacks.
> Without the identity management, you might not detect sending/receiving
> encrypted data from/to a MITM.
If you want to extend the Bitcoin protocol itself, you will have to resolve
that. Which many other solutions do (ssh for instance).
It would not be Ok to have an peer-to-peer encryption system that doesn't
allow non-pre-approved connections.
> > * 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.
>
> Most known use-case: SPV.
You didn't answer the question.
> > * 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.
>
> It's probably extremely inefficient to create a constant time stream.
Your use of "probably" makes me wonder if you already have an implementation.
Doing any encryption and handshaking design *without* actually having it coded
and gone though testing yet makes no sense.
I do not belief Bitcoin will benefit from "design by committee" where a
specification is drawn before an implementation is written.
Also, you didn't actually address the attack-vector.
> >> 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?
>
> Good point. Maybe one false try should lead to ignoring the peer.
That doesn't take away the resource attack at all.
> >> 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.
>
> This is a relative simple concept and does not require rehashing the
> whole communication.
Apologies, I should have been more clear; the BIP should specify the actual
algorithm, otherwise you can't create an implementation from just reading the
BIP.
Also, this may be a good time to ask why you want to have a per-message
encryption?
Practically every single popular end-to-end encryption uses one approach or
another were it just encrypts as another layer. (the L in ssl). You are
mixing layers, and unless you do that for a very good reason, or have a very
good reason why everyone else is doing it wrong, I suggest using a layered
encryption approach.
|
