From: Jonas Schnelli <dev@jonasschnelli•ch>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs
Date: Sat, 26 Mar 2016 10:01:36 +0100 [thread overview]
Message-ID: <56F64FF0.7060706@jonasschnelli.ch> (raw)
In-Reply-To: <4517402.JLxTDjem5X@garp>
[-- Attachment #1.1: Type: text/plain, Size: 2764 bytes --]
> I guess my question didn't get across.
>
> Why would you want to make your usecase do connections over the peer2peer
> (net.cpp) connection at all?
First, because there _are_ a hight amount of SPV wallets in the field.
SPV wallets are "dumb-clients" with only a tiny value for the bitcoin
network (they don't validate, they don't relay). They already are
decoupled wallets. We need solution that offers higher privacy and
higher traffic analysis resistance.
Using the p2p channel for communication between full validation peers
and wallet-only-peers makes sense IMO because wallet-only-peers can
slowly validate the chain and create a UTXO set in the background (could
take a couple of weeks) or solve other purposes that increases the
security and/or serving something back to the bitcoin network.
Sure, you can always use client/server wallets (Coinbase / Copay, etc.)
that offers SSL.
But I strongly recommend to improve the communication and interface
possibilities between wallet-nodes (SPV) and full-validation-nodes.
Otherwise we will very likely see centralization regarding end-user
wallets (with all the large risks of disrupting the community in case of
attacks/thefts, etc.).
_If we think Bitcoin should scale, we also need to scale and improve at
the point where users enter the network and start using Bitcoin._
> Mixing messages that are being sent to everyone and encrypted messages is
> asking for trouble.
> Making your private connection out-of-band would work much better.
The current encryption BIP requires to encrypt the complete traffic.
Having an option to do analysis resistant communication with a remote
peer within the protocol itself is something that is very valuable IMO.
>>> Also, you didn't actually address the attack-vector.
>>
>> Which attack-vector?
>
> The statistical attack I mentioned earlier. Which comes from knowing which
> plain text messages are being sent over the encrypted channel, So as long as
> you keep saying you want to encrypt data that identical copies of are being
> sent to other nodes at practically the same time, you will keep being
> vulnerable to that.
The encryption BIP recommends Chacha20-Poly1305 as encryption AEAD. This
is a very broad used encryption scheme (Google uses it to connect
Android phones with their cloud services).
Completely avoiding side channel on data analysis would probably require
extremely inefficient constant time encrypted datastreams.
Also, the BIP allows combining of multiple plaintext message in one
encrypted message.
Additionally we could extend the enc. BIP by allowing random padding of
encrypted messages or other techniques to reduce side channel analysis.
</jonas>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-03-26 9:01 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-23 15:24 Jonas Schnelli
2016-03-23 16:44 ` Tier Nolan
2016-03-23 20:36 ` Tom
2016-03-23 21:40 ` Eric Voskuil
2016-03-23 21:55 ` Jonas Schnelli
2016-03-25 10:36 ` Tom
2016-03-25 18:43 ` Jonas Schnelli
2016-03-25 20:42 ` Tom
2016-03-26 9:01 ` Jonas Schnelli [this message]
2016-03-26 23:23 ` James MacWhyte
2016-03-27 11:58 ` Jonas Schnelli
2016-03-27 17:04 ` James MacWhyte
2016-03-24 0:37 ` Sergio Demian Lerner
2016-03-24 2:16 ` Luke Dashjr
2016-03-24 17:20 ` Chris
2016-03-25 10:41 ` Tom
2016-03-25 7:17 ` Lee Clagett
2016-03-25 10:17 ` Jonas Schnelli
2016-04-01 21:09 ` Jonas Schnelli
2016-04-09 19:40 ` Lee Clagett
2016-05-18 8:00 ` Jonas Schnelli
2016-05-25 0:22 ` Lee Clagett
2016-05-25 9:36 ` Jonas Schnelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56F64FF0.7060706@jonasschnelli.ch \
--to=dev@jonasschnelli$(echo .)ch \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox