From: Thomas Voegtlin <thomasv1@gmx•de>
To: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Electrum 1.9.8 release
Date: Sun, 16 Mar 2014 15:31:24 +0100 [thread overview]
Message-ID: <5325B5BC.3030501@gmx.de> (raw)
In-Reply-To: <CAAS2fgR766pjD43bZawuJH9VQ7S0dQRGY9HetOuj9HR3Pk=1_A@mail.gmail.com>
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)
next prev parent reply other threads:[~2014-03-16 14:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-16 13:24 Thomas Voegtlin
2014-03-16 13:54 ` Gregory Maxwell
2014-03-16 14:31 ` Thomas Voegtlin [this message]
2014-03-16 14:39 ` Gregory Maxwell
2014-03-16 15:48 ` Thomas Voegtlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5325B5BC.3030501@gmx.de \
--to=thomasv1@gmx$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox