From: Lee Clagett <forum@leeclagett•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs
Date: Tue, 24 May 2016 20:22:50 -0400 [thread overview]
Message-ID: <20160524202250.01db6f61@laptop-m1330> (raw)
In-Reply-To: <573C212C.6070604@jonasschnelli.ch>
On Wed, 18 May 2016 10:00:44 +0200
Jonas Schnelli via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
wrote:
> Hi Lee
>
> Thank you very much for the valuable input.
> I'm still processing your feedback....
[...]
> > Why have a fixed MAC length? I think the MAC length should be
> > inferred from the cipher + authentication mode. And the Poly1305
> > tag is 16 bytes.
> >
> > *Unauthenticated Buffering*
> > Implementations are unlikely to (i.e. should not) process the
> > payload until authentication succeeds. Since the length field is 4
> > bytes, this means an implementation may have to buffer up to 4 GiB
> > of data _per connection_ before it can authenticate the length
> > field. If the outter length field were reduced to 2 or 3 bytes, the
> > unauthenticated buffering requirements drop to 64 KiB and 16 MiB
> > respectively. Inner messages already have their own length, so they
> > can span multiple encrypted blocks without other changes. This will
> > increase the bandwidth requirements when the size of a single
> > message exceeds 64 KiB or 16 MiB, since it will require multiple
> > authentication tags for that message. I think an additional 16
> > bytes per 16 MiB seems like a good tradeoff.
> >
>
> 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").
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.
[...]
>
> </jonas>
>
Lee
next prev parent reply other threads:[~2016-05-25 0:33 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
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 [this message]
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=20160524202250.01db6f61@laptop-m1330 \
--to=forum@leeclagett$(echo .)com \
--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