📅 Original date posted:2016-06-28
📝 Original message:There are two different topics mixed up here.
1. Link-level security (secure connection to the node we intended to connect to).
2. Node-level security (aka; don't connect to a 'evil node').
The fist requires link-level encryption and authentication.
The second requires identity authentication.
You described the 'evil node' attack; that indeed needs an identity system to stop. However BIP151 doesn't intend to protect against connecting to evil Bitcoin Nodes.
It is important not to mixup link-level authentication and node-level authentication.
When your client picks random nodes to connect to, you are not considered whom in particular runs them. (Rather that you have a good random sample of the network).
If you manually add a friends node; at this point you wish to have node-level authentication. However, this may (and probably should) happen out-of-band.
Sent from my iPhone
> On 29 Jun 2016, at 01:07, Eric Voskuil <eric at voskuil.org> wrote:
>
> Hi Cameron, good to hear from you!
>
>> On Jun 28, 2016, at 11:40 PM, Cameron Garnham <da2ce7 at gmail.com> wrote:
>>
>> Unauthenticated link level encryption is wonderful! MITM attacks are overrated; as they require an active attacker.
>
> This is not really the case with Bitcoin. A MITM attack does not require that the attacker find a way to inject traffic into the communication between nodes. Peers will connect to the attacker directly, or accept connections directly from it. Such attacks can be easier than even passive attacks.
>
>> Stopping passive attacks is the low hanging fruit. This should be taken first.
>>
>> Automated and secure peer authentication in a mesh network is a huge topic. One of the unsolved problems in computer science.
>>
>> A simple 'who is that' by asking for the fingerprint of your peers from your other peers is a very simple way to get 'some' authentication. Semi-trusted index nodes also is a low hanging fruit for authentication.
>
> It is the implication of widespread authentication that is at issue. Clearly there are ways to implement it using a secure side channels.
>
>> However, let's first get unauthenticated encryption. Force the attackers to use active attacks. (That are thousands times more costly to couduct).
>>
>> Sent from my iPhone
>>
>>> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> An "out of band key check" is not part of BIP151.
>>>
>>> It has a session ID for this purpose.
>>>
>>>> It requires a secure channel and is authentication. So BIP151 doesn't provide the tools to detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.
>>>
>>> One might wonder how you ever use a Bitcoin address, or even why we
>>> might guess these emails from "you" aren't actually coming from the
>>> NSA.
>>> _______________________________________________
>>> 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/20160629/49c7f475/attachment-0001.html>;
Cameron Garnham [ARCHIVE] /
npub1qh…chcrk
2023-06-07 17:51:39
in reply to nevent1q…r7ku
Author Public Key
npub1qhl358d8na8d3euj3aakeu394zx7q6pqc4a8u4p962k9mtrqdrvscchcrkPublished at
2023-06-07 17:51:39Event JSON
{
"id": "dd9a69b594c958e8c57568ffafcb4bc4dea68e8a93233e1d53cbb6515d6084bd",
"pubkey": "05ff1a1da79f4ed8e7928f7b6cf225a88de06820c57a7e5425d2ac5dac6068d9",
"created_at": 1686160299,
"kind": 1,
"tags": [
[
"e",
"d0e8bb25d553b30c0cc0d96d85855c267cf10b5981dd5042024df41c59046cbd",
"",
"root"
],
[
"e",
"1ba224947cc6c967a2872a9f368a83fb55caadc774e4cf13d5aa04bcf51e1756",
"",
"reply"
],
[
"p",
"82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e"
]
],
"content": "📅 Original date posted:2016-06-28\n📝 Original message:There are two different topics mixed up here.\n\n1. Link-level security (secure connection to the node we intended to connect to).\n\n2. Node-level security (aka; don't connect to a 'evil node').\n\nThe fist requires link-level encryption and authentication.\n\nThe second requires identity authentication.\n\nYou described the 'evil node' attack; that indeed needs an identity system to stop. However BIP151 doesn't intend to protect against connecting to evil Bitcoin Nodes.\n\nIt is important not to mixup link-level authentication and node-level authentication.\n\nWhen your client picks random nodes to connect to, you are not considered whom in particular runs them. (Rather that you have a good random sample of the network).\n\nIf you manually add a friends node; at this point you wish to have node-level authentication. However, this may (and probably should) happen out-of-band.\n\n\nSent from my iPhone\n\n\u003e On 29 Jun 2016, at 01:07, Eric Voskuil \u003ceric at voskuil.org\u003e wrote:\n\u003e \n\u003e Hi Cameron, good to hear from you!\n\u003e \n\u003e\u003e On Jun 28, 2016, at 11:40 PM, Cameron Garnham \u003cda2ce7 at gmail.com\u003e wrote:\n\u003e\u003e \n\u003e\u003e Unauthenticated link level encryption is wonderful! MITM attacks are overrated; as they require an active attacker.\n\u003e \n\u003e This is not really the case with Bitcoin. A MITM attack does not require that the attacker find a way to inject traffic into the communication between nodes. Peers will connect to the attacker directly, or accept connections directly from it. Such attacks can be easier than even passive attacks.\n\u003e \n\u003e\u003e Stopping passive attacks is the low hanging fruit. This should be taken first.\n\u003e\u003e \n\u003e\u003e Automated and secure peer authentication in a mesh network is a huge topic. One of the unsolved problems in computer science.\n\u003e\u003e \n\u003e\u003e A simple 'who is that' by asking for the fingerprint of your peers from your other peers is a very simple way to get 'some' authentication. Semi-trusted index nodes also is a low hanging fruit for authentication.\n\u003e \n\u003e It is the implication of widespread authentication that is at issue. Clearly there are ways to implement it using a secure side channels.\n\u003e \n\u003e\u003e However, let's first get unauthenticated encryption. Force the attackers to use active attacks. (That are thousands times more costly to couduct).\n\u003e\u003e \n\u003e\u003e Sent from my iPhone\n\u003e\u003e \n\u003e\u003e\u003e On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \n\u003e\u003e\u003e On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev\n\u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e An \"out of band key check\" is not part of BIP151.\n\u003e\u003e\u003e \n\u003e\u003e\u003e It has a session ID for this purpose.\n\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e It requires a secure channel and is authentication. So BIP151 doesn't provide the tools to detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.\n\u003e\u003e\u003e \n\u003e\u003e\u003e One might wonder how you ever use a Bitcoin address, or even why we\n\u003e\u003e\u003e might guess these emails from \"you\" aren't actually coming from the\n\u003e\u003e\u003e NSA.\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160629/49c7f475/attachment-0001.html\u003e",
"sig": "90ff895078b6cc3fd1824b2627b87076e652926affdeebac24918d6c2623e74e7f7aa869af8a44a995a967af93725c5be925459f18cce6323ed4169cc65bbf41"
}