📅 Original date posted:2015-10-05
📝 Original message:
On Sat, Oct 03, 2015 at 11:02:39AM -0700, Richard Kiss wrote:
> > Ah, it looks like the problem is that libsec256k1 actually goes a step
> > further and runs SHA256(y||x), where "x" is the value I'm getting and y
> > is '\x02' is the y value is even and '\x03' if it's odd. If I try both,
> > one of them turns out right:
> >
> > Unfortunately openssl throws away y and just gives us x, so I'm not sure
> > if I can work out the right secret directly. I guess I can run the HMAC
> > twice and pick the value that worked?
>
> My open source library pycoin has a function that will give you Y from X,
> so you can use that or just pilfer enough code to reproduce it (it's not
> native, but it's not a very complex operation).
Yep, but I'd still need to know whether to set is_even True or False,
which is what I'm trying to find out.
And if I want to be able to send onion messages not just forward them,
then I need to know. So to this end I've implemented ECDH directly (it's
just a single EC_POINT_mul operation afterall). Aside from a bug where I
was checking eveness by comparing the last byte to 0 rather than the
last bit, all good.
Still, it'd probably be friendlier to alternative implementations for
ECDH to only use the x value when creating secrets. I've added a comment
to an existing secp256k1 pull request to that effect:
https://github.com/bitcoin/secp256k1/pull/262#issuecomment-145473597
Cheers,
aj
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-09 12:44:43
in reply to nevent1q…wu9n
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-09 12:44:43Event JSON
{
"id": "a5d276062e225f62857fdf85fdc16f8bd92c393f7c834802caebf41cf104d0ce",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686314683,
"kind": 1,
"tags": [
[
"e",
"8068f367a334368b30aff76cd525cce9c5bc6d9781f504af87639b9a503f0531",
"",
"root"
],
[
"e",
"98dd36df4c1a0af63e6cd367a040c311c49168ac6d2c99d3be56c9d805438d2f",
"",
"reply"
],
[
"p",
"8e47fc91b77ea5383602890e640ba7a5d4547ac3d2790a72c63c9e9885c4fc22"
]
],
"content": "📅 Original date posted:2015-10-05\n📝 Original message:\nOn Sat, Oct 03, 2015 at 11:02:39AM -0700, Richard Kiss wrote:\n\u003e \u003e Ah, it looks like the problem is that libsec256k1 actually goes a step\n\u003e \u003e further and runs SHA256(y||x), where \"x\" is the value I'm getting and y\n\u003e \u003e is '\\x02' is the y value is even and '\\x03' if it's odd. If I try both,\n\u003e \u003e one of them turns out right:\n\u003e \u003e\n\u003e \u003e Unfortunately openssl throws away y and just gives us x, so I'm not sure\n\u003e \u003e if I can work out the right secret directly. I guess I can run the HMAC\n\u003e \u003e twice and pick the value that worked?\n\u003e \n\u003e My open source library pycoin has a function that will give you Y from X,\n\u003e so you can use that or just pilfer enough code to reproduce it (it's not\n\u003e native, but it's not a very complex operation).\n\nYep, but I'd still need to know whether to set is_even True or False,\nwhich is what I'm trying to find out.\n\nAnd if I want to be able to send onion messages not just forward them,\nthen I need to know. So to this end I've implemented ECDH directly (it's\njust a single EC_POINT_mul operation afterall). Aside from a bug where I\nwas checking eveness by comparing the last byte to 0 rather than the\nlast bit, all good.\n\nStill, it'd probably be friendlier to alternative implementations for\nECDH to only use the x value when creating secrets. I've added a comment\nto an existing secp256k1 pull request to that effect:\n\n https://github.com/bitcoin/secp256k1/pull/262#issuecomment-145473597\n\nCheers,\naj",
"sig": "1cb1e5d1ed79c5cfc44aaf689dcecebc440222b449c2a31d46a9583e7bacc993ff2aaff53aafff80c24baeaab7514dac0ee83ea0d4a18c550bdb1e72a9244793"
}