From aj at erisian.com.au  Mon Oct  5 14:49:00 2015
From: aj at erisian.com.au (Anthony Towns)
Date: Tue, 6 Oct 2015 00:49:00 +1000
Subject: [Lightning-dev] Onion routing strawman proposal
In-Reply-To: <CAOiHLquwZbh+ogjK8403qjSkGAS_04XUt-sEqB+FNu2qH-kDpg@mail.gmail.com>
References: <877fn5om6g.fsf@rustcorp.com.au> <20151003163855.GA22873@navy>
	<CAOiHLquwZbh+ogjK8403qjSkGAS_04XUt-sEqB+FNu2qH-kDpg@mail.gmail.com>
Message-ID: <20151005144900.GA23200@navy>

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