Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B29FF360
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 18 May 2016 08:00:54 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from server3 (server3.include7.ch [144.76.194.38])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id BDFD61C1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 18 May 2016 08:00:50 +0000 (UTC)
Received: by server3 (Postfix, from userid 115)
	id 7DB9E2E60257; Wed, 18 May 2016 10:00:49 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1
	autolearn=ham version=3.3.1
Received: from Jonass-MacBook-Pro.local (cable-static-140-182.teleport.ch
	[87.102.140.182]) by server3 (Postfix) with ESMTPSA id 7A8312D00144
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 18 May 2016 10:00:48 +0200 (CEST)
To: bitcoin-dev@lists.linuxfoundation.org
References: <56F2B51C.8000105@jonasschnelli.ch>
	<56FEE39B.3040401@jonasschnelli.ch>
	<20160409154038.4c04dd9b@laptop-m1330>
From: Jonas Schnelli <dev@jonasschnelli.ch>
Message-ID: <573C212C.6070604@jonasschnelli.ch>
Date: Wed, 18 May 2016 10:00:44 +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: <20160409154038.4c04dd9b@laptop-m1330>
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="R9vLIF4C0W1VqWB1DjUg51g9biojPEXRS"
Subject: Re: [bitcoin-dev] p2p authentication and encryption BIPs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 18 May 2016 08:00:54 -0000

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

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

Hi Lee

Thank you very much for the valuable input.
I'm still processing your feedback....

>=20
> *Key Revocation*
> This is probably too complicated, but an additional public key would
> allow for cold-storage key revocation. Spreading the knowledge of such
> an event is always painful, but it could be stored in the blockchain. I=

> think this is likely too complicated, but having these long-term keys
> constantly in memory/disk is unfortunate.
>=20

Yes. This could be something that could be extended once the BIP is
stable and/or implemented.



>> <code>K_1</code> must be used to only encrypt the payload size of the
>> encrypted message to avoid leaking information by revealing the
>> message size.=20
>>
>> <code>K_2</code> must be used in conjunction with poly1305 to build
>> an AEAD.
>=20
> Chacha20 is a stream cipher, so only a single encryption key is needed.=

> The first 32 bytes of the keystream would be used for the Poly1305 key,=

> the next 4 bytes would be used to encrypt the length field, and the
> remaining keystream would be used to encrypt the payload. Poly1305
> would then generate a tag over the length and payload. The receiver
> would generate the same keystream to decrypt the length which
> identifies the length of the message and the MAC offset, then
> authenticate the length and payload, then decypt with the remaining
> keystream.
>=20

Right. The AEAD construct I though of is probably called
chacha20-poly1305@openssh.com and specified in
https://github.com/openssh/openssh-portable/blob/05855bf2ce7d5cd0a6db18bc=
0b4214ed5ef7516d/PROTOCOL.chacha20poly1305#L34

I think this construct has already serval implementations and is widely
used.

I have updated the BIP to mention the chacha20-poly1305@openssh.com
specification.

> Is it safer to define two keys to prevent implementations from screwing=

> this up? You have to split the decryption and authentication, so the
> basic modes of libsodium cannot be used for instance. If a custom tag
> generation scheme is being used, then the basic modes are already
> unusable ...
>=20
> *Failed Authentication*
> What happens on a failed MAC attempt? Connection closure is the
> easiest way to handle the situation.

Yes. I think closing would make sense.

>> After a successful <code>encinit</code>/<code>encack</code>
>> interaction from both sides, the messages format must use the
>> "encrypted messages structure". Non-encrypted messages from the
>> requesting peer must lead to a connection termination (can be
>> detected by the 4 byte network magic in the unencrypted message
>> structure).
>=20
> The magic bytes are at the same offset and size as the encrypted length=

> field in the encrypted messages structure. So the magic bytes are not a=

> reliable way to identify unencrypted messages, although the probability=

> of collision is low.

Yes. This is a good point.
The implementation should probably also accept messages that contain the
4 byte network magic from unencrypted messages (to avoid possible
collisions).
If the message is unencrypted, the length check or the unsuccessful
authentication check will lead to a disconnect.

>> {|class=3D"wikitable"
>> ! Field Size !! Description !! Data type !! Comments
>> |-
>> | 4 || length || uint32_t || Length of ciphertext payload in number
>> of bytes
>> |-
>> | ? || ciphertext payload || ? || One or many ciphertext command &
>> message data
>> |-
>> | 8 || MAC tag || ? || MAC-tag truncated to 8 bytes
>> |}
>=20
> 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=
=2E
>=20
> *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.
>=20

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
>> A responding peer can inform the requesting peer over a re-keying
>> with a <code>encack</code> message containing 33byte of zeros to
>> indicate that all encrypted message following after this
>> <code>encack</code> message will be encrypted with ''the next
>> symmetric cipher key''.
>>
>> The new symmetric cipher key will be calculated by
>> <code>SHA256(SHA256(old_symetric_cipher_key))</code>.
>>
>> Re-Keying interval is a peer policy with a minimum timespan of 600
>> seconds.
>=20
> Should the int64_t message count be reset to 0 on a re-key? Or should
> the value reset to zero after 2^63-1? Hopefully the peer re-keys before=

> that rollover, or keystream reusage will occur. Unlikely that many
> messages are sent on a single connection though. And presumably this
> only re-keys the senders side? Bi-directional re-keying would be racy.

I just added the RFC4253 recommendation as a must (re-key after every
1GB of data sent or received).


</jonas>


--DQGjoA263WHgxIuEfubxjAU4pmRJ7Fg68--

--R9vLIF4C0W1VqWB1DjUg51g9biojPEXRS
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

iQIcBAEBCAAGBQJXPCEsAAoJECnUvLZBb1PskKAP/i9bNSyp6GnF82OHV6/fCQrb
XQKg9SWag3SK3/C+gsG3qNudL2LjqvjtzUNB1n8XHHLTunLgh9GT7R/NlXup2sX4
4uA0PFJYr77eV0dJFv/IHOqV7YUzQGvignLoTpW/zzoIeg/vHv45k05wMMsApwCq
EG8qnvLmXJ8jh4S0+8PHQfhvB4X39aao9zaUaDRFFGDGqzydRpWxrtUHwUrXycdU
2VFp0pYt6u3WGVS6FmKZu06+27No9b1cPofQj7WG6KbTIGBq9JS/f+dTvx7R1C4m
HBDg1lI19M8e0Qo70LR5htrnlu0XStdIt+Q2S1LXGEi29/pi0K7HEqeEdZN/Ylhc
8XSCYZAAK1/FIagspLqdMzOaT7ipdK8kTNr9IDgmRpy25xN+h5UfwaoQ2DI/TAkO
5O9ZhfEDp40yeYx34on3XYc+rr/nVUS/V8MbpNSzdSFOCbwV9oDJb41dw41+yFIo
MAPPDHygmV/mdDzF7/J0xcjG96nSXwVEY9zW5hnkQJ8r9hnsBWR+5Yj8iVJc/aIn
wWE9+Nm1LMvl2AZaBS1/pbEmkJLayyobjmfQx11B4D3gk900eiO+M+BHOohMNHpr
S8mzEDLo8sn5vxc/wQ0r/ETwfNh+Z7q5KnHQHuq8qEaiPnVeTA9mhpK+t7GHpMPs
ilYqHZvh4y8a4RAspfyN
=IKw6
-----END PGP SIGNATURE-----

--R9vLIF4C0W1VqWB1DjUg51g9biojPEXRS--