Zooko Wilcox-OHearn [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-16 📝 Original message: I'm so happy to see this ...
📅 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
📝 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