Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-17 📝 Original message: > > > > > > I'm happy to ...
📅 Original date posted:2015-12-17
📝 Original message:
>
>
> >
> > I'm happy to the crypto experts debate AES-CTR + HMAC-SHA-256 (which I
> used) vs ChaCha20+poly1035.
>
> I'd prefer ChaCha20+poly1305.
>
Welcome aboard the Cha Cha Train! [1]
>
> > 128 bits definitely seems a bit tight for node ids: I assumed a full
> > bitcoin EC pubkey in my current implementation.
>
> I have a pretty good sense of how risky short node ids are, but I
> don't have a good idea of how costly long node ids are in this
> context. I also don't know how many node ids are likely to exist in
> the long-run, successful scenario. 10⁹? 10¹²? Not more than 10¹⁵!
>
> I'd suggest 192-bit nodeids, based on such musings as:
>
> *
> http://ecrypt-eu.blogspot.de/2015/11/break-dozen-secret-keys-get-million.html
>
> * http://www.keylength.com/en/compare/
>
> I feel confident that 192-bit nodeids are safe enough. Whether they
> are, practically speaking, more efficient than 256-bit nodeids I'll
> leave up to you to answer.
>
>
Currently, in our code, node ID's take two forms: either the hash160
(Bitcoin style) of a node's current pub-key or the raw serialized pub-key
itself. This is done such that "nodeID at host" locators explicitly provide a
level of backwards (p2pkh) compatibility for end wallets that are unable to
establish a connection in a timely manner.
Within the Sphinx mix-header, I think we should be safely able to truncate
this (the hash160) to 16-bytes. In the case of a collision, the onion-route
propagation across the incorrect node will simply fail, as it won't be able
to properly derive the shared secret.
Otherwise, we'd be forced to ditch chacha20+poly3015 for
AES-CTR+SHA-256-HMAC within Sphinx if serialized pub-keys are used for node
ID's in the routing info.
> > 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 :)
>
>
I can't blame him! Utilizing HORNET's rendezvous protocol will allow for a
high level of privacy for both sender *and* receiver.
>
> > 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.
> >
>
>
Sure. If we end up going with cha cha, I'd like us to adopt the practice of
encrypting the packet lengths with a separate key (and a new instance of
chacha20) similar to openssh's chacha20-poly3015 specification[2]. With
this construction, packet-length+packet-payload remain confidential.
> > PS. Are we having fun yet?
>
>
Definitely! On my Winter Break atm, so getting a chance to catch up on all
the fun I missed out on during this past quarter :)
1. https://www.youtube.com/watch?v=xGQ5OOyuaxs
2.
https://tools.ietf.org/html/draft-josefsson-ssh-chacha20-poly1305-openssh-00
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151217/94f6241d/attachment.html>;
📝 Original message:
>
>
> >
> > I'm happy to the crypto experts debate AES-CTR + HMAC-SHA-256 (which I
> used) vs ChaCha20+poly1035.
>
> I'd prefer ChaCha20+poly1305.
>
Welcome aboard the Cha Cha Train! [1]
>
> > 128 bits definitely seems a bit tight for node ids: I assumed a full
> > bitcoin EC pubkey in my current implementation.
>
> I have a pretty good sense of how risky short node ids are, but I
> don't have a good idea of how costly long node ids are in this
> context. I also don't know how many node ids are likely to exist in
> the long-run, successful scenario. 10⁹? 10¹²? Not more than 10¹⁵!
>
> I'd suggest 192-bit nodeids, based on such musings as:
>
> *
> http://ecrypt-eu.blogspot.de/2015/11/break-dozen-secret-keys-get-million.html
>
> * http://www.keylength.com/en/compare/
>
> I feel confident that 192-bit nodeids are safe enough. Whether they
> are, practically speaking, more efficient than 256-bit nodeids I'll
> leave up to you to answer.
>
>
Currently, in our code, node ID's take two forms: either the hash160
(Bitcoin style) of a node's current pub-key or the raw serialized pub-key
itself. This is done such that "nodeID at host" locators explicitly provide a
level of backwards (p2pkh) compatibility for end wallets that are unable to
establish a connection in a timely manner.
Within the Sphinx mix-header, I think we should be safely able to truncate
this (the hash160) to 16-bytes. In the case of a collision, the onion-route
propagation across the incorrect node will simply fail, as it won't be able
to properly derive the shared secret.
Otherwise, we'd be forced to ditch chacha20+poly3015 for
AES-CTR+SHA-256-HMAC within Sphinx if serialized pub-keys are used for node
ID's in the routing info.
> > 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 :)
>
>
I can't blame him! Utilizing HORNET's rendezvous protocol will allow for a
high level of privacy for both sender *and* receiver.
>
> > 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.
> >
>
>
Sure. If we end up going with cha cha, I'd like us to adopt the practice of
encrypting the packet lengths with a separate key (and a new instance of
chacha20) similar to openssh's chacha20-poly3015 specification[2]. With
this construction, packet-length+packet-payload remain confidential.
> > PS. Are we having fun yet?
>
>
Definitely! On my Winter Break atm, so getting a chance to catch up on all
the fun I missed out on during this past quarter :)
1. https://www.youtube.com/watch?v=xGQ5OOyuaxs
2.
https://tools.ietf.org/html/draft-josefsson-ssh-chacha20-poly1305-openssh-00
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151217/94f6241d/attachment.html>;