Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2016-06-08 📝 Original message:On Wed, Jun 8, 2016 at ...
📅 Original date posted:2016-06-08
📝 Original message:On Wed, Jun 8, 2016 at 11:47 PM, Alfie John via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi folks,
>
> Overall I think BIP 151 is a good idea. However unless I'm mistaken, what's to
> prevent someone between peers to suppress the initial 'encinit' message during
> negotiation, causing both to fallback to plaintext?
>
> Peers should negotiate a secure channel from the outset or backout entirely
> with no option of falling back. This can be indicated loudly by the daemon
> listening on an entirely new port.
Reduction to plaintext isn't an interesting attack vector for an
active attacker: they can simply impersonate the remote side.
This is addressed via authentication, where available, which is done
by a separate specification that builds on this one.
Without authentication this only provides protection against passive attackers.
📝 Original message:On Wed, Jun 8, 2016 at 11:47 PM, Alfie John via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi folks,
>
> Overall I think BIP 151 is a good idea. However unless I'm mistaken, what's to
> prevent someone between peers to suppress the initial 'encinit' message during
> negotiation, causing both to fallback to plaintext?
>
> Peers should negotiate a secure channel from the outset or backout entirely
> with no option of falling back. This can be indicated loudly by the daemon
> listening on an entirely new port.
Reduction to plaintext isn't an interesting attack vector for an
active attacker: they can simply impersonate the remote side.
This is addressed via authentication, where available, which is done
by a separate specification that builds on this one.
Without authentication this only provides protection against passive attackers.