public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs
Date: Wed, 25 May 2016 11:36:24 +0200	[thread overview]
Message-ID: <57457218.6060804@jonasschnelli.ch> (raw)
In-Reply-To: <20160524202250.01db6f61@laptop-m1330>


[-- Attachment #1.1: Type: text/plain, Size: 2509 bytes --]


>> Good point.
>> I have mentioned this now in the BIP but I think the BIP should allow
>> message > 16 MiB.
>> I leave the max. message length up to the implementation while keeping
>> the 4 byte length on the protocol level.
> 
> I expect the implementation defined max size to work (SSH 2.0 does this
> after all), but I want to make sure my suggestion is understood
> completely.
> 
> There is a length field for the encrypted data, and length field(s)
> inside of the encrypted data to indicate the length of the plaintext
> Bitcoin messages. I am suggesting that the outter (encrypted) length
> field be reduced, which will _not limit_ the length of Bitcoin
> messages. For example, if a 1 GiB Bitcoin message needed to be sent
> and the encrypted length field was 3 bytes - the sender is forced to
> send a minimum of 64 MACs for this message. The tradeoff is allowing
> the receiver to detect malformed data sooner and have a lower max
> buffering window **against** slightly higher bandwidth and CPU
> requirements due to the additional headers+MACs (the CPU requirements
> should primarily be in "finalizing each Poly1305").

Okay. Got your point.
The current BIPs assumption is that an encrypted package/message can
contain 1..n bitcoin messages (a single bitcoin message distributed over
multiple encrypted messages/packages was not specified).

But right, this could make sense.
Let me think this through....

> An alternative way to think about the suggestion is tunnelling Bitcoin
> messages over TLS or SSH. TLS 1.2 has a 2-byte length field and SSH 2.0
> a 4-byte length field, but neither prevents larger Bitcoin messages from
> being tunnelled; the lengths are independent.

TLS/SSH tunneling is already possible with third party software like
stunnel.
Also there is promising projects that would encrypt the traffic "on a
deeper layer" (see CurveCP).

I think what we want is a simple, openssl-independent traffic encryption
built into the core p2p layer.

IMO the risk of screwing up the implementation is moderate.

The implementation is not utterly-complex:
OpenSSH chacha20:
https://github.com/openssh/openssh-portable/blob/0235a5fa67fcac51adb564cba69011a535f86f6b/chacha.c

Chacha20-Poly1305:
https://github.com/openssh/openssh-portable/blob/0235a5fa67fcac51adb564cba69011a535f86f6b/cipher-chachapoly.c

Sure. Before an implementation will be deployed to the endusers it will
require intense cryptoanalysis first.

</jonas>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

      reply	other threads:[~2016-05-25  9:36 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
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 [this message]

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=57457218.6060804@jonasschnelli.ch \
    --to=dev@jonasschnelli.ch \
    --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