Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-15 📝 Original message: > > Not sure where these ...
📅 Original date posted:2015-12-15
📝 Original message:
>
> 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.
> 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.
> 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)).
HORNET seems a bit over-the-horizon for now
>
Agreed! Sphinx should be sufficient for now.
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).
1. https://tools.ietf.org/html/rfc7539 (Section 4)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151215/ac6be70f/attachment.html>;
📝 Original message:
>
> 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.
> 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.
> 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)).
HORNET seems a bit over-the-horizon for now
>
Agreed! Sphinx should be sufficient for now.
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).
1. https://tools.ietf.org/html/rfc7539 (Section 4)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151215/ac6be70f/attachment.html>;