From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B29FF360 for ; 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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. >> K_1 must be used to only encrypt the payload size of the >> encrypted message to avoid leaking information by revealing the >> message size.=20 >> >> K_2 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 encinit/encack >> 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 encack message containing 33byte of zeros to >> indicate that all encrypted message following after this >> encack message will be encrypted with ''the next >> symmetric cipher key''. >> >> The new symmetric cipher key will be calculated by >> SHA256(SHA256(old_symetric_cipher_key)). >> >> 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). --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--