Electrum 1.9.8 release

Electrum 1.9.8 release
2014-03-16 13:54 ` Gregory Maxwell
  
From: Thomas Voegtlin @ 2014-03-16 13:24 UTC (permalink / raw)
  To: bitcoin-development

I am happy to announce the release of Electrum 1.9.8.
This release includes some features initially planned for version 2.0.

Packages are available on https://electrum.org/download.html (signed by me)
Binaries for windows and mac will be available in the coming days

enjoy

Thomas
-----------------------

RELEASE NOTES

# Release 1.9.8

(This release includes features initially planned for version 2.0)

* Electrum servers were upgraded to version 0.9. The new server stores
   a Patrica tree of all UTXOs, an idea proposed by Alan Reiner in the
   bitcointalk forum. This property allows the client to directly
   request the balance of any address. The new commands are:
      1. getaddressbalance <address>
      2. getaddressunspent <address>
      3. getutxoaddress <txid> <pos>

* In addition, two commands for message encryption were added:
      1. encrypt <pubkey> <message>
      2. decrypt <pubkey> <message>

   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 encrypt and decrypt functions are available in the Qt GUI (from
   the menubar, or right click on one of your addresses if you want to
   use its public key).

* Command-line commands that require a connection to the network spawn
   a daemon, that remains connected and handles subsequent
   commands. The daemon terminates itself if it remains unused for more
   than one minute. The purpose of this is to make scripting more
   efficient. For example, a bash script using many electrum commands
   will open only one connection.




 permalink raw reply	[|nested]
2014-03-16 13:24 [Bitcoin-development] Electrum 1.9.8 release Thomas Voegtlin

  2014-03-16 14:31   ` Thomas Voegtlin
  
From: Gregory Maxwell @ 2014-03-16 13:54 UTC (permalink / raw)
  To: Thomas Voegtlin;  Bitcoin Development

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)



 permalink raw reply	[|nested]
2014-03-16 13:54 ` Gregory Maxwell

  2014-03-16 14:39     ` Gregory Maxwell
  
From: Thomas Voegtlin @ 2014-03-16 14:31 UTC (permalink / raw)
  To: Bitcoin Development

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)




 permalink raw reply	[|nested]
2014-03-16 14:31   ` Thomas Voegtlin

  2014-03-16 15:48       ` Thomas Voegtlin
  
From: Gregory Maxwell @ 2014-03-16 14:39 UTC (permalink / raw)
  To: Thomas Voegtlin;  Bitcoin Development

On Sun, Mar 16, 2014 at 7:31 AM, Thomas Voegtlin <thomasv1@gmx•de> wrote:
> 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.

It also leaks on the order of 7 bits of data about the message per
message chunk.  I'm also think it's likely that there are some
messages which are just incorrectly decrypted.   ... it's really
screwy and suspect.



 permalink raw reply	[|nested]
2014-03-16 14:39     ` Gregory Maxwell

  
From: Thomas Voegtlin @ 2014-03-16 15:48 UTC (permalink / raw)
  To: Bitcoin Development

Thanks again for having a look.

Given these problems, I have decided to remove
the encryption methods from the current release.
I retagged 1.9.8 and updated the packages.

Thomas



Le 16/03/2014 15:39, Gregory Maxwell a écrit :
> On Sun, Mar 16, 2014 at 7:31 AM, Thomas Voegtlin <thomasv1@gmx•de> wrote:
>> 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.
> It also leaks on the order of 7 bits of data about the message per
> message chunk.  I'm also think it's likely that there are some
> messages which are just incorrectly decrypted.   ... it's really
> screwy and suspect.




 permalink raw reply	[|nested]