From: Gregory Maxwell <gmaxwell@gmail•com>
To: Thomas Voegtlin <thomasv1@gmx•de>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Electrum 1.9.8 release
Date: Sun, 16 Mar 2014 06:54:49 -0700 [thread overview]
Message-ID: <CAAS2fgR766pjD43bZawuJH9VQ7S0dQRGY9HetOuj9HR3Pk=1_A@mail.gmail.com> (raw)
In-Reply-To: <5325A61B.6050802@gmx.de>
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 13:54 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 [this message]
2014-03-16 14:31 ` Thomas Voegtlin
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='CAAS2fgR766pjD43bZawuJH9VQ7S0dQRGY9HetOuj9HR3Pk=1_A@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=thomasv1@gmx$(echo .)de \
/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