📅 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>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 12:45:27
in reply to nevent1q…t0wg
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 12:45:27Event JSON
{
"id": "accc4bdfbdc5ae6214b0fb82c50c3b000b09babb95f2d5ee93dd2b300a83c811",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686314727,
"kind": 1,
"tags": [
[
"e",
"a0eae0709b098880fb92a837f655fe2ac84b7ed07fa439abcde3b595cd8022fc",
"",
"root"
],
[
"e",
"aeac86465bd2bd0a156756df8890a61b62e7e876c3f269bfee6655123052077c",
"",
"reply"
],
[
"p",
"1566edf7bbd095daee0204bea4dde8abd464c270cdf185ccc31e95b074bd460b"
]
],
"content": "📅 Original date posted:2015-12-17\n📝 Original message:\n\u003e\n\u003e\n\u003e \u003e\n\u003e \u003e I'm happy to the crypto experts debate AES-CTR + HMAC-SHA-256 (which I\n\u003e used) vs ChaCha20+poly1035.\n\u003e\n\u003e I'd prefer ChaCha20+poly1305.\n\u003e\n\nWelcome aboard the Cha Cha Train! [1]\n\n\n\u003e\n\u003e \u003e 128 bits definitely seems a bit tight for node ids: I assumed a full\n\u003e \u003e bitcoin EC pubkey in my current implementation.\n\u003e\n\u003e I have a pretty good sense of how risky short node ids are, but I\n\u003e don't have a good idea of how costly long node ids are in this\n\u003e context. I also don't know how many node ids are likely to exist in\n\u003e the long-run, successful scenario. 10⁹? 10¹²? Not more than 10¹⁵!\n\u003e\n\u003e I'd suggest 192-bit nodeids, based on such musings as:\n\u003e\n\u003e *\n\u003e http://ecrypt-eu.blogspot.de/2015/11/break-dozen-secret-keys-get-million.html\n\u003e\n\u003e * http://www.keylength.com/en/compare/\n\u003e\n\u003e I feel confident that 192-bit nodeids are safe enough. Whether they\n\u003e are, practically speaking, more efficient than 256-bit nodeids I'll\n\u003e leave up to you to answer.\n\u003e\n\u003e\nCurrently, in our code, node ID's take two forms: either the hash160\n(Bitcoin style) of a node's current pub-key or the raw serialized pub-key\nitself. This is done such that \"nodeID at host\" locators explicitly provide a\nlevel of backwards (p2pkh) compatibility for end wallets that are unable to\nestablish a connection in a timely manner.\n\nWithin the Sphinx mix-header, I think we should be safely able to truncate\nthis (the hash160) to 16-bytes. In the case of a collision, the onion-route\npropagation across the incorrect node will simply fail, as it won't be able\nto properly derive the shared secret.\n\nOtherwise, we'd be forced to ditch chacha20+poly3015 for\nAES-CTR+SHA-256-HMAC within Sphinx if serialized pub-keys are used for node\nID's in the routing info.\n\n\n\u003e \u003e Matts was really interested in sending messages over LN, though, so no\n\u003e \u003e doubt he'll be salivating at the idea of extending in this direction :)\n\u003e\n\u003e\nI can't blame him! Utilizing HORNET's rendezvous protocol will allow for a\nhigh level of privacy for both sender *and* receiver.\n\n\n\u003e\n\u003e \u003e Sure, let's discuss that. I want to modify the handshake anyway to\n\u003e \u003e include a \u003clen\u003e prefix (like every other message). This lets us upgrade\n\u003e \u003e the crypto later, by appending a key for a different system.\n\u003e \u003e\n\u003e\n\u003e\nSure. If we end up going with cha cha, I'd like us to adopt the practice of\nencrypting the packet lengths with a separate key (and a new instance of\nchacha20) similar to openssh's chacha20-poly3015 specification[2]. With\nthis construction, packet-length+packet-payload remain confidential.\n\n\n\u003e \u003e PS. Are we having fun yet?\n\u003e\n\u003e\nDefinitely! On my Winter Break atm, so getting a chance to catch up on all\nthe fun I missed out on during this past quarter :)\n\n1. https://www.youtube.com/watch?v=xGQ5OOyuaxs\n2.\nhttps://tools.ietf.org/html/draft-josefsson-ssh-chacha20-poly1305-openssh-00\n\n-- Laolu\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151217/94f6241d/attachment.html\u003e",
"sig": "d262b760ff7cf66a47c208064a7069e2b5555a61fc58e90f26a26aa584dc045ad4fb11676e5b2023097b4428db3b9e3958b87289eb1f41df51dd7dfb815d13ef"
}