public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs
Date: Wed, 23 Mar 2016 21:37:25 -0300	[thread overview]
Message-ID: <CAKzdR-r7T2vC2dtvN1=PHzFox8T78wQMaYy+=1DezPOtRHNrjQ@mail.gmail.com> (raw)
In-Reply-To: <1983116.UNQS71VxHo@garp>

[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3119 bytes --]

  parent reply	other threads:[~2016-03-24  0:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-23 15:24 [bitcoin-dev] p2p authentication and encryption BIPs 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
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 [this message]
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='CAKzdR-r7T2vC2dtvN1=PHzFox8T78wQMaYy+=1DezPOtRHNrjQ@mail.gmail.com' \
    --to=sergio.d.lerner@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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