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 CD9CFDB3 for ; Thu, 6 Sep 2018 23:23:27 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AA73D7A6 for ; Thu, 6 Sep 2018 23:23:26 +0000 (UTC) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 8C247487BA; Fri, 7 Sep 2018 01:23:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de [80.241.56.115]) (amavisd-new, port 10030) with ESMTP id LZaIpt6NtZOJ; Fri, 7 Sep 2018 01:23:22 +0200 (CEST) Message-ID: <061aa38d8ceeb6caaae19d7c86e435a5f86b293b.camel@timruffing.de> From: Tim Ruffing To: Jonas Schnelli , Bitcoin Protocol Discussion Date: Fri, 07 Sep 2018 01:23:21 +0200 In-Reply-To: <640D015D-3DDB-43C4-9752-96ADABF64C91@jonasschnelli.ch> References: <640D015D-3DDB-43C4-9752-96ADABF64C91@jonasschnelli.ch> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 06 Sep 2018 23:33:25 +0000 Subject: Re: [bitcoin-dev] Overhauled BIP151 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: Thu, 06 Sep 2018 23:23:27 -0000 Hi Jonas, Great to see progress in this area. I have quite a few comments. Post-quantum key exchange ========================= I think that's overkill. Bitcoin has huge problems in the presence of a quantum computer, and the confidentiality of the P2P messages is the most minor one. If there is a quantum computer and Bitcoin remains in its current form, then people should probably stop using it. Now you can argue that the attacker is storing encrypted traffic today to decrypt it later. Sure, but if that's your threat model then Bitcoin is probably not the right tool for you. (And if you insist that Bitcoin is the right tool, then you can and probably should use it over Tor anyway.) Given the fact that essentially all information in Bitcoin will be public in some way, there are probably cheaper attacks (MITM, traffic analysis). It's not worth the hassle, would hinder adoption, and it has the potential to create a wrong impression of "bulletproof" security. Even worse, there will be too many people that will suddenly assume that Bitcoin is post-quantum secure. Key exchange indistinguishable from random ========================================== I would rather love to see a simple ECDH key exchange as currently used but with an encoding of public key that provides indistinguishability from random bitstrings. "Elligator" does not work but "Elligator Squared" [1] does the job for secp256k1 -- it just doubles the size of the public key. Together with the encrypted packet lengths, the entire data stream looks like random then, which is pretty useful against censorship resistance for example. (The only exception is that the stream will never start with the magic bytes.) Key derivation ============== The key derivation can be improved. It should include each peer's understanding of its role, i.e., requester (or "initiator" is the more common term) or responder. At the moment, an attacker can create a situation where two peers think they're in the same session (with the same session id) but they're actually not. Also, it's possible for an attacker to rerandomize the public keys. That's nothing bad by itself but anything which restricts the flexibility of the attacker without adding complexity is a good idea. Something like "salt = BitcoinSharedSecret||INITIATOR_PUBKEY||RESPONDER_PUBKEY" should just avoid this issue. Re-keying ========= The problem with signalling re-keying in the length field is that the length field is not covered by the MAC. So the attacker can flip the signalling bit. The resulting protocol is probably still secure but the malleability is certainly not desirable. Deterministic rekeying rules may be better. Otherwise there will be implementations that rekey every 10 seconds and implementations that just don't rekey at all (rendering the 10 s rekeying interval in the opposite direction useless). Different policies also make it possible to fingerprint implementations. Another problem is that people will set their policies arbitrarily. What's better: 5 min or 30 min? I don't know, but both are reasonable choices. (Thats's very much like discussions about ciphers... What's better AES-GCM or ChaCha20/Poly1305? I don't know, but again both are reasonable choices.) Symmetric crypto ================ You call it chacha20-poly1305@bitcoin but what's the difference to the openssh then? Is the idea to save a call to chacha here as you mentioned? I didn't think about this in detail: maybe there are a few meaningful cases where padding could hide the message length without too much overhead. (I'm not convinced, just a random thought.) Misc ==== "The ID/string mapping is a peer to peer arrangement and MAY be negotiated between the requesting and responding peer." I think that's overly complicated. I suggest it should just be written in stone, again to avoid complexity and to avoid fingerprinting. New implementations are necessary anyway, so maybe just use IDs for anything? ASCII is nice if you want to debug your code or some random network failure but that's hard anyway when encryption is used. In general, the entire thing is a little bit underspecified. (I'm aware it's just a draft.) A few examples: - What should a peer do if the MAC verification fails? - What should a peer do if it receives an even key? - "Processing the message before the authentication succeeds (MAC verified) MUST not be done." That should also apply to the ciphertext. (Or: What is a "message"?). It may be a good idea to to refer to the openssh document or steal from it; it does a pretty good job. - "Both peers MUST keep track of the message sequence number (uint32) of sent and received messages for building a 64-bit symmetric cipher IV." I think you mean nonce when you say IV? - What is the initial value of the sequence number? - How is a 64-bit nonce formed from one (two?) uint32? - What if the uint32 overflows? - "Re-Keying interval is a peer policy with a minimum timespan of 10 seconds." What if I receive too many re-keying requests? Nothing or should I raise the DoS score? - "The Re-Keying must be done after every 1GB of data sent or received" Hm, every peer updates its own sending key, so this should just read "sent" instead of "sent or received"? Pseudocode could probably help here. [1] https://eprint.iacr.org/2014/043.pdf