📅 Original date posted:2015-12-15
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
>>
>> Not sure where these numbers come from? The current header overhead is
>> sha256 (32 bytes) + pubkey (33 bytes), or 1300 bytes. (Don't be
>> confused by the current test implementation which doesn't serialize the
>> pubkey).
>>
>
> Hmm, I pulled those numbers from here:
> http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-October/000247.html:
> "That's a fixed 3840 bytes; each node decrypts and removed the tail entry,
> then prepends padding." Perhaps there's been a newer iteration I've missed,
> or the 3.8K bytes isn't the true serialized size.
Hi Roasbeef!
Ah, that includes payloads for each node, though, not just the headers.
There's stuff in there for Future Use.
>> If we were to cut to a 16 byte MAC (which seems unwise)
>
> With Poly1035 (which takes 32-byte key and produces a 16-byte tag), forged
> messages are rejected with a probability of 1-(n/(2^102)) for a 16n-byte
> message[1]. Since the MAC is computed over the 656 byte (20 hops, s=16)
> routing-info portion (the onion-wrapped part of the mix header), forged
> tags will be rejected with a probability of 1-(656/(2^102)), which seems
> okay to me.
Ah, I hadn't appreciated that poly1035 was 128 bit tags already! Let's
argue it in the crypto thread which we'll start. I'm happy to the
crypto experts debate AES-CTR + HMAC-SHA-256 (which I used) vs
ChaCha20+poly1035.
It's a simple change, code-wise.
>> Or, if we're standarizing on ChaCha20, with a 32-byte key:
>>
>> 33 + (2 * 20 + 2) * 32 = 1377 bytes.
>>
>
> Apologies for the ambiguity, but, the "(..)*16" (s) more accurately refers
> to the size of the HMAC and node ID's. So if using ChaCha for a stream
> cipher, and Poly1035 for MACs rather than AES-CTR + a truncated
> SHA-256-HMAC, the size remains the same. Either AES-CTR or ChaCha20 are
> valid candidates for the required stream-cipher in the Sphinx construction.
>
> As an side, my current implementation uses AES-CTR as a stream cipher, and
> a truncated SHA-256-HMAC for the MAC (s=20). It was written before we
> cozied up to ChaCha20-Poly1035. I'll be porting it over to ChaCha-Poly3015
> once I tick off some more high-priority items from my TODO list (assuming
> we're comfortable with 16-byte node ID's, node ID's are used to map to a
> node's current DH-key (id -> key)).
128 bits definitely seems a bit tight for node ids: I assumed a full
bitcoin EC pubkey in my current implementation.
> HORNET seems a bit over-the-horizon for now
>>
>
> Agreed! Sphinx should be sufficient for now.
Matts was really interested in sending messages over LN, though, so no
doubt he'll be salivating at the idea of extending in this direction :)
> Great! Let's argue about protobufs and ChaCha20 vs AES before then :)
>>
>
> Perhaps in a new thread :)
>
> Oh, and also, we've come up with a slight variation on the current proposed
> p2p crypto handshake. It builds off of the current method (ephemerals
> first, etc.). I should get around to posting it to the ML sometime
> tomorrow+1 (I'd like to make sure it's sound).
Sure, let's discuss that. I want to modify the handshake anyway to
include a <len> prefix (like every other message). This lets us upgrade
the crypto later, by appending a key for a different system.
> 1. https://tools.ietf.org/html/rfc7539 (Section 4)
That's a definite MUST READ for any implementer...
Thanks!
Rusty.
PS. Are we having fun yet?
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:45:26
in reply to nevent1q…ygnp
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:45:26Event JSON
{
"id": "57e1e1a0ff8f7a357d2331d4a24ffbc3d9d11d15dadd9e777cc9af801615c8cb",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314726,
"kind": 1,
"tags": [
[
"e",
"a0eae0709b098880fb92a837f655fe2ac84b7ed07fa439abcde3b595cd8022fc",
"",
"root"
],
[
"e",
"1650b93b86b578a6eb6b16064100e533130e8a25d78deb5c5472aeafa3c981ce",
"",
"reply"
],
[
"p",
"2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476"
]
],
"content": "📅 Original date posted:2015-12-15\n📝 Original message:\nOlaoluwa Osuntokun \u003claolu32 at gmail.com\u003e writes:\n\u003e\u003e\n\u003e\u003e Not sure where these numbers come from? The current header overhead is\n\u003e\u003e sha256 (32 bytes) + pubkey (33 bytes), or 1300 bytes. (Don't be\n\u003e\u003e confused by the current test implementation which doesn't serialize the\n\u003e\u003e pubkey).\n\u003e\u003e\n\u003e\n\u003e Hmm, I pulled those numbers from here:\n\u003e http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-October/000247.html:\n\u003e \"That's a fixed 3840 bytes; each node decrypts and removed the tail entry,\n\u003e then prepends padding.\" Perhaps there's been a newer iteration I've missed,\n\u003e or the 3.8K bytes isn't the true serialized size.\n\nHi Roasbeef!\n\nAh, that includes payloads for each node, though, not just the headers.\nThere's stuff in there for Future Use.\n\n\u003e\u003e If we were to cut to a 16 byte MAC (which seems unwise)\n\u003e\n\u003e With Poly1035 (which takes 32-byte key and produces a 16-byte tag), forged\n\u003e messages are rejected with a probability of 1-(n/(2^102)) for a 16n-byte\n\u003e message[1]. Since the MAC is computed over the 656 byte (20 hops, s=16)\n\u003e routing-info portion (the onion-wrapped part of the mix header), forged\n\u003e tags will be rejected with a probability of 1-(656/(2^102)), which seems\n\u003e okay to me.\n\nAh, I hadn't appreciated that poly1035 was 128 bit tags already! Let's\nargue it in the crypto thread which we'll start. I'm happy to the\ncrypto experts debate AES-CTR + HMAC-SHA-256 (which I used) vs\nChaCha20+poly1035.\n\nIt's a simple change, code-wise.\n\n\u003e\u003e Or, if we're standarizing on ChaCha20, with a 32-byte key:\n\u003e\u003e\n\u003e\u003e 33 + (2 * 20 + 2) * 32 = 1377 bytes.\n\u003e\u003e\n\u003e\n\u003e Apologies for the ambiguity, but, the \"(..)*16\" (s) more accurately refers\n\u003e to the size of the HMAC and node ID's. So if using ChaCha for a stream\n\u003e cipher, and Poly1035 for MACs rather than AES-CTR + a truncated\n\u003e SHA-256-HMAC, the size remains the same. Either AES-CTR or ChaCha20 are\n\u003e valid candidates for the required stream-cipher in the Sphinx construction.\n\u003e\n\u003e As an side, my current implementation uses AES-CTR as a stream cipher, and\n\u003e a truncated SHA-256-HMAC for the MAC (s=20). It was written before we\n\u003e cozied up to ChaCha20-Poly1035. I'll be porting it over to ChaCha-Poly3015\n\u003e once I tick off some more high-priority items from my TODO list (assuming\n\u003e we're comfortable with 16-byte node ID's, node ID's are used to map to a\n\u003e node's current DH-key (id -\u003e key)).\n\n128 bits definitely seems a bit tight for node ids: I assumed a full\nbitcoin EC pubkey in my current implementation.\n\n\u003e HORNET seems a bit over-the-horizon for now\n\u003e\u003e\n\u003e\n\u003e Agreed! Sphinx should be sufficient for now.\n\nMatts was really interested in sending messages over LN, though, so no\ndoubt he'll be salivating at the idea of extending in this direction :)\n\n\u003e Great! Let's argue about protobufs and ChaCha20 vs AES before then :)\n\u003e\u003e\n\u003e\n\u003e Perhaps in a new thread :)\n\u003e\n\u003e Oh, and also, we've come up with a slight variation on the current proposed\n\u003e p2p crypto handshake. It builds off of the current method (ephemerals\n\u003e first, etc.). I should get around to posting it to the ML sometime\n\u003e tomorrow+1 (I'd like to make sure it's sound).\n\nSure, let's discuss that. I want to modify the handshake anyway to\ninclude a \u003clen\u003e prefix (like every other message). This lets us upgrade\nthe crypto later, by appending a key for a different system.\n\n\u003e 1. https://tools.ietf.org/html/rfc7539 (Section 4)\n\nThat's a definite MUST READ for any implementer...\n\nThanks!\nRusty.\nPS. Are we having fun yet?",
"sig": "83acd0ed4b4dc310d1b63abf26d13e1ca795a4903a6c5cf68556375673ef5616653c8e653a0d0aff3b46966a1c5eca7266569660c7ca1342d57d5026b88f6bec"
}