To: bitcoin-dev@lists.linuxfoundation.org
References: <56F2B51C.8000105@jonasschnelli.ch>
	<56FEE39B.3040401@jonasschnelli.ch>
	<20160409154038.4c04dd9b@laptop-m1330>
	<573C212C.6070604@jonasschnelli.ch>
	<20160524202250.01db6f61@laptop-m1330>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <57457218.6060804@jonasschnelli.ch>
Date: Wed, 25 May 2016 11:36:24 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
	Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <20160524202250.01db6f61@laptop-m1330>
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="DN473J4fxqsHUgGBtCBbfCqjGcrbQ2nHe"
Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--DN473J4fxqsHUgGBtCBbfCqjGcrbQ2nHe
Content-Type: multipart/mixed; boundary="B08LAIBXFE4TV0JeCjTHRVMG2qKeGwTMU"
From: Jonas Schnelli <dev@jonasschnelli.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <57457218.6060804@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs
References: <56F2B51C.8000105@jonasschnelli.ch>
 <56FEE39B.3040401@jonasschnelli.ch> <20160409154038.4c04dd9b@laptop-m1330>
 <573C212C.6070604@jonasschnelli.ch> <20160524202250.01db6f61@laptop-m1330>
In-Reply-To: <20160524202250.01db6f61@laptop-m1330>

--B08LAIBXFE4TV0JeCjTHRVMG2qKeGwTMU
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


>> 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.
>=20
> 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.
>=20
> 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 fro=
m
> 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/0235a5fa67fcac51adb564cb=
a69011a535f86f6b/chacha.c

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

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

</jonas>


--B08LAIBXFE4TV0JeCjTHRVMG2qKeGwTMU--

--DN473J4fxqsHUgGBtCBbfCqjGcrbQ2nHe
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXRXIYAAoJECnUvLZBb1PsnCkP/13tmyamj1c6DeJV89LZbmCa
LSEUPqh08sKiiNxV1y3Tqg97NTLwyz436WUEeLlEEa4Nxvkj3dD3ctGh4wQRMYSD
onobpBUL33oOM02+r3TznlMYPMwXaif+vfOjOcQZnj54XS/PpoVKGf7oDkrEF1Sh
TjiqMe9807gn4Yhg77mTsMTF+H/qjMW+i1Y75OUvcU0C3oPjcSkH+waifggGV9q/
1W6H/6Kw3JY4Ce0j+u2FA2JrLY2Qti56U5bG+hJ3Qn8SVJlXcTWrNL0gPxGLHBop
dVJXYNR0X59OXQg+K6TGvX+Tyf4ErMwN98tzfTD1sWVbso+rfvJxVHQ+2Oi1hOQg
Gg7NX+in082+We3ymFVuT4RC31a6kzXSMV21XKJkzJL5HCuzuOqtwA8cTlmeDaub
y3WBK39wz4fm8J7tayw3TxuuHCySgR4uJVXK/r+eU9Mz7DEJ4AVIxy1Qt52vxjKc
M9vnXAIoOzER/44lldtTaidAG97u1runyMltUNzbmdCLXXqWU+GnIpkemax7B6oP
UFD2Htw+Jx5lMSTYOSW04FyS5W4bMjKS0R66scElcj1SI9nPX8l3MxRPTqzteb34
SH5t6HNKKgIA9rQcOIJiK0WyKRLBsjSvTDhYlDChURdzRUuWNn95tZKEPnP2ma12
Ph4fK5DHk+8KfGYQ+FBE
=Cvl4
-----END PGP SIGNATURE-----

--DN473J4fxqsHUgGBtCBbfCqjGcrbQ2nHe--