waxwing on Nostr: Read the thread for context. I think it's interesting to compare other situations ...
Read the thread for context.
I think it's interesting to compare other situations where signatures get used a lot on keys. A good one might be lightning: in that case, they use a noise-based transport protocol to encrypt the actual tx messages etc, as well as onion routing. however, channel counterparties by definition will see a lot of messages on the same key; just not, 1000s, usually it'll be more like 10s (but that can be enough for lattice attacks to work). Another example is TLS, it's been years since I studied it but iirc it starts with a diffie hellman exchange, not a signature; signatures are used for the PKI part (that is, the certificates presented by the server (not usually client) to the client are signed by an authority in a tree structure; i guess technically this can result in a lot of signatures on single authority keys, so there could be conceivably attacks there).
I'm certainly not sure but I think the continued use of RFC6979 is a tremendous bastion of defence against all these attacks (and the algo is changed in BIP340 signing but it's just a simpler version, it should give the same result - no nonce bias). The area of concern might be more likely the cooperative protocols where deterministic nonces can't be used (see the MuSig bip for some discussion).
I sadly somewhat agree. I had a discussion ~ 1.5 yrs ago on here with someone where we both had the same thought: what saves bitcoin users from slightly weak nonces being dangerous to their funds is non-address reuse. (I recommend the paper "biased nonce-sense" by Tanja Lange et al on this). If you use nostr keys as bitcoin keys then even 1 or 2 bits of bias in your nonce generation could be enough to lose the funds.
Published at
2024-08-11 19:02:00Event JSON
{
"id": "abfcc2e5ec549fa6504273a601edb8feb91494f7c0f945ab3b675babac489527",
"pubkey": "675b84fe75e216ab947c7438ee519ca7775376ddf05dadfba6278bd012e1d728",
"created_at": 1723402920,
"kind": 1,
"tags": [
[
"e",
"552cd0c3b9a79a5c57aefd5312dba6c170e601e4278dd705e214c811f1f1c133",
"",
"mention"
],
[
"p",
"675b84fe75e216ab947c7438ee519ca7775376ddf05dadfba6278bd012e1d728",
"",
"mention"
]
],
"content": "Read the thread for context.\n\nI think it's interesting to compare other situations where signatures get used a lot on keys. A good one might be lightning: in that case, they use a noise-based transport protocol to encrypt the actual tx messages etc, as well as onion routing. however, channel counterparties by definition will see a lot of messages on the same key; just not, 1000s, usually it'll be more like 10s (but that can be enough for lattice attacks to work). Another example is TLS, it's been years since I studied it but iirc it starts with a diffie hellman exchange, not a signature; signatures are used for the PKI part (that is, the certificates presented by the server (not usually client) to the client are signed by an authority in a tree structure; i guess technically this can result in a lot of signatures on single authority keys, so there could be conceivably attacks there).\n\nI'm certainly not sure but I think the continued use of RFC6979 is a tremendous bastion of defence against all these attacks (and the algo is changed in BIP340 signing but it's just a simpler version, it should give the same result - no nonce bias). The area of concern might be more likely the cooperative protocols where deterministic nonces can't be used (see the MuSig bip for some discussion).\n\nnostr:nevent1qqs92txscwu60xju27h065cjmwnvzu8xq8jz0rwhqh3pfjq378cuzvcpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgsxwkuyle67y94tj378gw8w2xw2wa6nwmwlqhddlwnz0z7sztsaw2qrqsqqqqqpm4l5x3",
"sig": "257410fb8af82d6b81810ae782ccdaab2be7ccf343673ac4c426d2780ff343f881e4e7699de2f606c3a3cc34b8818824339e8f8063184b5c17cf3ae814354175"
}
