ð
Original date posted:2016-03-23
ð Original message:It seems that every message must be signed (the protocols lacks MACs). This
can be very resource consuming in terms of CPU and bandwidth since most p2p
messages are small.
On Wed, Mar 23, 2016 at 5:36 PM, Tom via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wednesday 23 Mar 2016 16:24:12 Jonas Schnelli via bitcoin-dev wrote:
> > Hi
> >
> > I have just PRed a draft version of two BIPs I recently wrote.
> > https://github.com/bitcoin/bips/pull/362
>
> I suggest running a spellchecker ;)
>
> Some questions;
>
> * why would you not allow encryption on non-pre-approved connections?
> * we just removed (ssl) encryption from the JSON interface, how do you
> suggest
> this encryption to be implemented without openSSL?
> * What is the reason for using the p2p code to connect a wallet to a node?
> I suggest using one of the other connection methods to connect to the node.
> This avoids a change in the bitcoin protocol for a very specific usecase.
> * Why do you want to do a per-message encryption (wrapping the original)?
> Smaller messages that contain predictable content and are able to be
> matched
> to the unencrypted versions on the wire send to other nodes will open this
> scheme up to various old statistical attacks.
>
> > Responding peers must ignore (banning would lead to fingerprinting) the
> requesting peer after 5 unsuccessfully authentication tries to avoid
> resource
> attacks.
>
> Any implementation of that kind would itself again be open to resource
> attacks.
> Why 5? Do you want to allow a node to make a typo?
>
>
> > To ensure that no message was dropped or blocked, the complete
> communication
> must be hashed (sha256). Both peers keep the SHA256 context of the
> encryption
> session. The complete <code>enc</code> message (leaving out the hash
> itself)
> must be added to the hash-context by both parties. Before sending a
> <code>enc</code> command, the sha256 context will be copied and finalized.
>
> You write "the complete communication must be hashed" and every message
> has a
> hash of the state until it is at that point.
> I think you need to explain how that works specifically.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160323/adfd13d4/attachment.html>;
Sergio Demian Lerner [ARCHIVE] /
npub1fvâŠ3vq7f
2023-06-07 17:49:59
in reply to nevent1qâŠ5tdy
Author Public Key
npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7fPublished at
2023-06-07 17:49:59Event JSON
{
"id": "f7ac7b4871a120924d70883e0a1c9a330953839428bbed666d8b230217f5b547",
"pubkey": "4b38603408f5be002091210e869a4ca86fc2aa1ffd0871036a0668068ee626ee",
"created_at": 1686160199,
"kind": 1,
"tags": [
[
"e",
"1c87d471b2f2da141b64e0a9c480b3ca53986e57331a196cd0234d6c8fb75484",
"",
"root"
],
[
"e",
"2549c95ea69fab6f3767cbf4c002dc7cf75ef20f49b3c2d3fd0f845377a376f2",
"",
"reply"
],
[
"p",
"52e5d0646af3ea5ccb6c4bd31237d6068258a11ace3ac40f02466a3f89342928"
]
],
"content": "ð
Original date posted:2016-03-23\nð Original message:It seems that every message must be signed (the protocols lacks MACs). This\ncan be very resource consuming in terms of CPU and bandwidth since most p2p\nmessages are small.\n\n\nOn Wed, Mar 23, 2016 at 5:36 PM, Tom via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Wednesday 23 Mar 2016 16:24:12 Jonas Schnelli via bitcoin-dev wrote:\n\u003e \u003e Hi\n\u003e \u003e\n\u003e \u003e I have just PRed a draft version of two BIPs I recently wrote.\n\u003e \u003e https://github.com/bitcoin/bips/pull/362\n\u003e\n\u003e I suggest running a spellchecker ;)\n\u003e\n\u003e Some questions;\n\u003e\n\u003e * why would you not allow encryption on non-pre-approved connections?\n\u003e * we just removed (ssl) encryption from the JSON interface, how do you\n\u003e suggest\n\u003e this encryption to be implemented without openSSL?\n\u003e * What is the reason for using the p2p code to connect a wallet to a node?\n\u003e I suggest using one of the other connection methods to connect to the node.\n\u003e This avoids a change in the bitcoin protocol for a very specific usecase.\n\u003e * Why do you want to do a per-message encryption (wrapping the original)?\n\u003e Smaller messages that contain predictable content and are able to be\n\u003e matched\n\u003e to the unencrypted versions on the wire send to other nodes will open this\n\u003e scheme up to various old statistical attacks.\n\u003e\n\u003e \u003e Responding peers must ignore (banning would lead to fingerprinting) the\n\u003e requesting peer after 5 unsuccessfully authentication tries to avoid\n\u003e resource\n\u003e attacks.\n\u003e\n\u003e Any implementation of that kind would itself again be open to resource\n\u003e attacks.\n\u003e Why 5? Do you want to allow a node to make a typo?\n\u003e\n\u003e\n\u003e \u003e To ensure that no message was dropped or blocked, the complete\n\u003e communication\n\u003e must be hashed (sha256). Both peers keep the SHA256 context of the\n\u003e encryption\n\u003e session. The complete \u003ccode\u003eenc\u003c/code\u003e message (leaving out the hash\n\u003e itself)\n\u003e must be added to the hash-context by both parties. Before sending a\n\u003e \u003ccode\u003eenc\u003c/code\u003e command, the sha256 context will be copied and finalized.\n\u003e\n\u003e You write \"the complete communication must be hashed\" and every message\n\u003e has a\n\u003e hash of the state until it is at that point.\n\u003e I think you need to explain how that works specifically.\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160323/adfd13d4/attachment.html\u003e",
"sig": "81043521c966147a1daeb238d079863214fecb3fc4b1e3bffa79d198c96a08484cb52c24d85348daf8b5e13b6a1628155315b4ff34289a0743533415b9a8db42"
}