From aj at erisian.com.au  Sun Oct  4 05:57:17 2015
From: aj at erisian.com.au (Anthony Towns)
Date: Sun, 4 Oct 2015 15:57:17 +1000
Subject: [Lightning-dev] Onion routing strawman proposal
In-Reply-To: <20151003163855.GA22873@navy>
References: <877fn5om6g.fsf@rustcorp.com.au>
 <20151003163855.GA22873@navy>
Message-ID: <20151004055717.GA14108@navy>

On Sun, Oct 04, 2015 at 02:38:56AM +1000, Anthony Towns wrote:
> Sigh. I've had a go at reimplementing it in python, but ...

But nothing! The decoding/forwarding is successfully working in python
with pyelliptic. (I'm running the HMAC twice rather than actually working
out y)

$ test/test_onion 15 > TEST.OUT
$ python test/test_onion.py < TEST.OUT
Message to 0
Message to 1
Message to 2
Message to 3
Message to 4
Message to 5
Message to 6
Message to 7
Message to 8
Message to 9
Message to 10
Message to 11
Message to 12
Message to 13
Message to 14
done

I changed test_onion.c to output the generated node keypairs (private
key and non-compressed public key) and to dump the first message, like
so:

$ grep -v Decrypting TEST.OUT | tail -n3 | cut -c1-300
 * Keypair 13: 3f62802944de7ca5894e5759d351adac869580ec17e485f18c0c66f17cc07cbb 047d1b9ad310727493cf5fab067ec9b7476eac30eca03348ddce13f63f73ccce235dfa2807ab608a81628df72aa29d16c284379e8a48e2ddc1b98cfccf07c12a42
 * Keypair 14: 22fce466da610b63af62bc83b4692f3affaf271693ac071fb86d11342d8def4f 045319588ea4788b57452821af386aaf25842c96e680fc3a0f16076bd4bf21f1647144bc5ff1e492fcb6c12c1f893a02dc5d12ba85d96d4eaea0faaeded0f452fa
 * Message: 9c9e39281020fe4e4193ba2c1147753038c88e7ca98f4cbc1e074011fc0f85f15dd7576d9e400779eff31b27872b7762e1844447a92772a0bd495f86389a9ae0eae16f0f8dff246d57156a3a5aa36ebae2eaafd50e3bb7e08fc6b97e435b8e62f715980068f23bcf6c177d50b61507efdaf377fd1de20374ca556ec323acd7533e19031c36945e895be7935ec9d6c181

Eh, I made it a pull request; those are fun right?

https://github.com/ElementsProject/lightning/pull/8

Some notes:

 - AES128 just uses the first half of the calculated enckey, iv and
   pad_iv
 - I couldn't get pyCrypto's AES128 to work -- I think because I wasn't
   sure exactly how openssl turns an "IV" into a "counter". I couldn't
   find docs on what openssl is trying to do here either, but didn't
   bother looking at the source
 - since libsecp256k1 already sha256s the ecdh secret; the hmac/enckey/etc
   end up being sha256'ed twice (with a byte added in between). confused
   me for a minute.

Cheers,
aj