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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1WPBWl-00037m-SG
for bitcoin-development@lists.sourceforge.net;
Sun, 16 Mar 2014 13:54:59 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.175 as permitted sender)
client-ip=209.85.217.175; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f175.google.com;
Received: from mail-lb0-f175.google.com ([209.85.217.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WPBWh-0007ii-SB
for bitcoin-development@lists.sourceforge.net;
Sun, 16 Mar 2014 13:54:59 +0000
Received: by mail-lb0-f175.google.com with SMTP id w7so2937396lbi.6
for <bitcoin-development@lists.sourceforge.net>;
Sun, 16 Mar 2014 06:54:49 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.3.72 with SMTP id a8mr1575001laa.33.1394978089284; Sun,
16 Mar 2014 06:54:49 -0700 (PDT)
Received: by 10.112.184.226 with HTTP; Sun, 16 Mar 2014 06:54:49 -0700 (PDT)
In-Reply-To: <5325A61B.6050802@gmx.de>
References: <5325A61B.6050802@gmx.de>
Date: Sun, 16 Mar 2014 06:54:49 -0700
Message-ID: <CAAS2fgR766pjD43bZawuJH9VQ7S0dQRGY9HetOuj9HR3Pk=1_A@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Thomas Voegtlin <thomasv1@gmx.de>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1WPBWh-0007ii-SB
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Electrum 1.9.8 release
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: Sun, 16 Mar 2014 13:55:00 -0000
On Sun, Mar 16, 2014 at 6:24 AM, Thomas Voegtlin <thomasv1@gmx.de> wrote:
> The encryption algorithm is ECIES, and code was was borrowed from
> https://github.com/jackjack-jj/jeeq. In order to know the public
> key corresponding to a Bitcoin address in your wallet, you can use
> the 'getpubkeys' command. The 'decrypt' command assumes that the
> wallet has the private key corresponding to the public key passed as
> argument.
The cryptosystem in that repository appears to be insecure in several
ways and is not actually implementing ECIES.
The most important of which is that instead of using a
cryptographically strong mac tied to the ephemeral secret it uses a
trivial 16 bit check value. This means that that I can decode an
arbitrary message encrypted to a third person if they allow me to make
no more than 65536 queries to a decryption oracle to decrypt some
other message.
Also, in the event that a random query to a decryption oracle yields a
result (1:2^16 times) the result directly reveals the ECDH value
because it is only additively combined with the message value. If the
implementation does not check if the nonce point is on the curve (an
easy implementation mistake) the result can yield a point on the twist
instead of the curve which is far more vulnerable to recovery of the
private key. ECIES uses a KDF instead of using the ECDH result
directly to avoid this.
There may be other problems (or mitigating factors) as it was very
hard for me to follow what it was actually doing.
(The particular implementation has a number of other issues, like
apparently not using a cryptographically strong RNG for its EC nonce..
but I assume you didn't copy that particular flaw)
|
