Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmx.de
	designates 212.227.17.21 as permitted sender)
	client-ip=212.227.17.21; envelope-from=thomasv1@gmx.de;
	helo=mout.gmx.net; 
Message-ID: <5325B5BC.3030501@gmx.de>
Date: Sun, 16 Mar 2014 15:31:24 +0100
From: Thomas Voegtlin <thomasv1@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
References: <5325A61B.6050802@gmx.de>
	<CAAS2fgR766pjD43bZawuJH9VQ7S0dQRGY9HetOuj9HR3Pk=1_A@mail.gmail.com>
In-Reply-To: <CAAS2fgR766pjD43bZawuJH9VQ7S0dQRGY9HetOuj9HR3Pk=1_A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Bitcoin-development] Electrum 1.9.8 release
Precedence: list

thanks for your feedback!

I was not aware that that implementation was flawed.
I will see how I can fix that code and get back to you.

Thomas


Le 16/03/2014 14:54, Gregory Maxwell a écrit :
> 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)