📅 Original date posted:2014-03-16
📝 Original message: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 at 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)
Thomas Voegtlin [ARCHIVE] /
npub10f…7ej47
2023-06-07 15:15:47
in reply to nevent1q…el2d
Author Public Key
npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47Published at
2023-06-07 15:15:47Event JSON
{
"id": "f6c3880fb934513136e8daf0480cebd4cf03b8207e802b7a43c4eb385dd0bd9e",
"pubkey": "7a4ba40070e54012212867182c66beef592603fe7c7284b72ffaafce9da20c05",
"created_at": 1686150947,
"kind": 1,
"tags": [
[
"e",
"af00beff456b08069ca61bc26e24a501ff89f447fc579a1aa96fc66edda13389",
"",
"root"
],
[
"e",
"38658515e88c42cbbd1c4db772d099925cca935d0085179642392d4f9397590b",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2014-03-16\n📝 Original message:thanks for your feedback!\n\nI was not aware that that implementation was flawed.\nI will see how I can fix that code and get back to you.\n\nThomas\n\n\n\nLe 16/03/2014 14:54, Gregory Maxwell a écrit :\n\u003e On Sun, Mar 16, 2014 at 6:24 AM, Thomas Voegtlin \u003cthomasv1 at gmx.de\u003e wrote:\n\u003e\u003e The encryption algorithm is ECIES, and code was was borrowed from\n\u003e\u003e https://github.com/jackjack-jj/jeeq. In order to know the public\n\u003e\u003e key corresponding to a Bitcoin address in your wallet, you can use\n\u003e\u003e the 'getpubkeys' command. The 'decrypt' command assumes that the\n\u003e\u003e wallet has the private key corresponding to the public key passed as\n\u003e\u003e argument.\n\u003e The cryptosystem in that repository appears to be insecure in several\n\u003e ways and is not actually implementing ECIES.\n\u003e\n\u003e The most important of which is that instead of using a\n\u003e cryptographically strong mac tied to the ephemeral secret it uses a\n\u003e trivial 16 bit check value. This means that that I can decode an\n\u003e arbitrary message encrypted to a third person if they allow me to make\n\u003e no more than 65536 queries to a decryption oracle to decrypt some\n\u003e other message.\n\u003e\n\u003e Also, in the event that a random query to a decryption oracle yields a\n\u003e result (1:2^16 times) the result directly reveals the ECDH value\n\u003e because it is only additively combined with the message value. If the\n\u003e implementation does not check if the nonce point is on the curve (an\n\u003e easy implementation mistake) the result can yield a point on the twist\n\u003e instead of the curve which is far more vulnerable to recovery of the\n\u003e private key. ECIES uses a KDF instead of using the ECDH result\n\u003e directly to avoid this.\n\u003e\n\u003e There may be other problems (or mitigating factors) as it was very\n\u003e hard for me to follow what it was actually doing.\n\u003e\n\u003e (The particular implementation has a number of other issues, like\n\u003e apparently not using a cryptographically strong RNG for its EC nonce..\n\u003e but I assume you didn't copy that particular flaw)",
"sig": "e2490c11d40c73fc8def3ced2795cf510dd6f39416b522a21c4a14686a29958d8c03a6895aca5489d3f0ed403ea66e678bf5107848f73fa17df7467d71a45762"
}