📅 Original date posted:2015-12-16
📝 Original message:
I'm so happy to see this direction of re-using prior work — SPHINX —
instead of inventing a new wheel. Thank you, roasbeef!
On Tue, Dec 15, 2015 at 11:38 PM, Rusty Russell <rusty at rustcorp.com.au> wrote:
>
> I'm happy to the crypto experts debate AES-CTR + HMAC-SHA-256 (which I used) vs ChaCha20+poly1035.
I'd prefer ChaCha20+poly1305.
> 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.
> 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 :)
☺
> 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...
+1! Please don't assume that your endpoint can reliably update
persistent state, and if at all possible don't assume that your
platform's CSPRNG is good. This is the weakest point in the system
IMHO, based on empirical evidence.
A good way to strengthen this weak point is to mix persistent state,
*and* platform CSPRNG, *and* mix in unique and/or private information
from the current protocol state, so that if any of those one is good
then your nonce is unique and your key unguessable.
> PS. Are we having fun yet?
YES!
Regards,
Zooko
Zooko Wilcox-OHearn [ARCHIVE] /
npub1z4…684vc
2023-06-09 12:45:26
in reply to nevent1q…ttgy
Author Public Key
npub1z4nwmaam6z2a4mszqjl2fh0g402xfsnsehcctnxrr62mqa9agc9sv684vcPublished at
2023-06-09 12:45:26Event JSON
{
"id": "aeac86465bd2bd0a156756df8890a61b62e7e876c3f269bfee6655123052077c",
"pubkey": "1566edf7bbd095daee0204bea4dde8abd464c270cdf185ccc31e95b074bd460b",
"created_at": 1686314726,
"kind": 1,
"tags": [
[
"e",
"a0eae0709b098880fb92a837f655fe2ac84b7ed07fa439abcde3b595cd8022fc",
"",
"root"
],
[
"e",
"57e1e1a0ff8f7a357d2331d4a24ffbc3d9d11d15dadd9e777cc9af801615c8cb",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-12-16\n📝 Original message:\nI'm so happy to see this direction of re-using prior work — SPHINX —\ninstead of inventing a new wheel. Thank you, roasbeef!\n\nOn Tue, Dec 15, 2015 at 11:38 PM, Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\u003e\n\u003e I'm happy to the crypto experts debate AES-CTR + HMAC-SHA-256 (which I used) vs ChaCha20+poly1035.\n\nI'd prefer ChaCha20+poly1305.\n\n\u003e 128 bits definitely seems a bit tight for node ids: I assumed a full\n\u003e bitcoin EC pubkey in my current implementation.\n\nI have a pretty good sense of how risky short node ids are, but I\ndon't have a good idea of how costly long node ids are in this\ncontext. I also don't know how many node ids are likely to exist in\nthe long-run, successful scenario. 10⁹? 10¹²? Not more than 10¹⁵!\n\nI'd suggest 192-bit nodeids, based on such musings as:\n\n* http://ecrypt-eu.blogspot.de/2015/11/break-dozen-secret-keys-get-million.html\n\n* http://www.keylength.com/en/compare/\n\nI feel confident that 192-bit nodeids are safe enough. Whether they\nare, practically speaking, more efficient than 256-bit nodeids I'll\nleave up to you to answer.\n\n\u003e Matts was really interested in sending messages over LN, though, so no\n\u003e doubt he'll be salivating at the idea of extending in this direction :)\n\n☺\n\n\u003e Sure, let's discuss that. I want to modify the handshake anyway to\n\u003e include a \u003clen\u003e prefix (like every other message). This lets us upgrade\n\u003e the crypto later, by appending a key for a different system.\n\u003e\n\u003e\u003e 1. https://tools.ietf.org/html/rfc7539 (Section 4)\n\u003e\n\u003e That's a definite MUST READ for any implementer...\n\n+1! Please don't assume that your endpoint can reliably update\npersistent state, and if at all possible don't assume that your\nplatform's CSPRNG is good. This is the weakest point in the system\nIMHO, based on empirical evidence.\n\nA good way to strengthen this weak point is to mix persistent state,\n*and* platform CSPRNG, *and* mix in unique and/or private information\nfrom the current protocol state, so that if any of those one is good\nthen your nonce is unique and your key unguessable.\n\n\u003e PS. Are we having fun yet?\n\nYES!\n\nRegards,\n\nZooko",
"sig": "ad12caf170d9222b989406b025bd72f2660a9763e0be9ae9e2d0007470928eba1403015efad469ad3957f577685214d3e648648ff8b7c146e50d0b83d478c200"
}