From: Tom Zander <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org,
	Jonas Schnelli <dev@jonasschnelli.ch>
Date: Wed, 08 Mar 2017 22:25:46 +0100
Message-ID: <18390846.ckRIaq9dAb@strawberry>
In-Reply-To: <30362205-D0CC-46D9-B924-EFA0A6EA1AC9@jonasschnelli.ch>
References: <BL2PR03MB435C5077E69D91D0A8092B6EE2A0@BL2PR03MB435.namprd03.prod.outlook.com>
	<D4B674DB-8F2E-4AA1-B271-FEE02A62A274@voskuil.org>
	<30362205-D0CC-46D9-B924-EFA0A6EA1AC9@jonasschnelli.ch>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] Unique node identifiers (and BIP150)
Precedence: list

On Wednesday, 8 March 2017 20:47:54 CET Jonas Schnelli via bitcoin-dev=20
wrote:
> Please Eric. Stop spreading FUD.
> BIP150 has a fingerprint-free **OPTIONAL** authentication. It=E2=80=99s d=
esigned
> to not reveal any node identifier/identity without first get a
> crypto.-proof from other peer that he already knows your identity.
> **Peers can=E2=80=99t be identified without having the identity-keys pre =
shared
> by the node operators.**

Do you know the trick of having an open wifi basestation in a public street=
=20
and how that can lead to tracking? Especially if you have a network of them.
The trick is this; you set up an open wifi base station with a hidden ssid=
=20
and phones try to connect to it by saying =E2=80=9CAre you ssid=3Dxyz?=E2=
=80=9D
This leads the basestation to know that the phone has known credentials wit=
h=20
another wifi that has a specific ssid. (the trick is slightly more elaborat=
e,=20
but the basics are relevant here).

Your BIP is vulnarable to the same issue, as a node wants to connect using=
=20
the AUTHCHALLENGE which has as an argument the hash of the person I=E2=80=
=99m trying=20
to connect with.

Your BIP says "Fingerprinting the requesting peer is not possible=E2=80=9D.
Unfortunately, this is wrong. Yes the peer is trivial to fingerprint. Your=
=20
hash never changes and as you connect to a node anyone listening can see yo=
u=20
sending the same hash on every connect to that peer, whereever you are or=20
connect from.

Just like the wifi hack.

I think you want to use industry standards instead, and a good start may be=
=20
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
=2D-=20
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel