bf8b34d36f9877fcb4d7b65d5fd33bb224a773
1 Return-Path: <crypto@timruffing.de> 2 Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org 3 [172.17.192.35]) 4 by mail.linuxfoundation.org (Postfix) with ESMTPS id CD9CFDB3 5 for <bitcoin-dev@lists.linuxfoundation.org>; 6 Thu, 6 Sep 2018 23:23:27 +0000 (UTC) 7 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 8 Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215]) 9 by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AA73D7A6 10 for <bitcoin-dev@lists.linuxfoundation.org>; 11 Thu, 6 Sep 2018 23:23:26 +0000 (UTC) 12 Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) 13 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) 14 (No client certificate requested) 15 by mx2.mailbox.org (Postfix) with ESMTPS id 8C247487BA; 16 Fri, 7 Sep 2018 01:23:24 +0200 (CEST) 17 X-Virus-Scanned: amavisd-new at heinlein-support.de 18 Received: from smtp1.mailbox.org ([80.241.60.240]) 19 by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de 20 [80.241.56.115]) (amavisd-new, port 10030) 21 with ESMTP id LZaIpt6NtZOJ; Fri, 7 Sep 2018 01:23:22 +0200 (CEST) 22 Message-ID: <061aa38d8ceeb6caaae19d7c86e435a5f86b293b.camel@timruffing.de> 23 From: Tim Ruffing <crypto@timruffing.de> 24 To: Jonas Schnelli <dev@jonasschnelli.ch>, Bitcoin Protocol Discussion 25 <bitcoin-dev@lists.linuxfoundation.org> 26 Date: Fri, 07 Sep 2018 01:23:21 +0200 27 In-Reply-To: <640D015D-3DDB-43C4-9752-96ADABF64C91@jonasschnelli.ch> 28 References: <640D015D-3DDB-43C4-9752-96ADABF64C91@jonasschnelli.ch> 29 Content-Type: text/plain; charset="UTF-8" 30 Mime-Version: 1.0 31 Content-Transfer-Encoding: 7bit 32 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW 33 autolearn=ham version=3.3.1 34 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on 35 smtp1.linux-foundation.org 36 X-Mailman-Approved-At: Thu, 06 Sep 2018 23:33:25 +0000 37 Subject: Re: [bitcoin-dev] Overhauled BIP151 38 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org 39 X-Mailman-Version: 2.1.12 40 Precedence: list 41 List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> 42 List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 43 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> 44 List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> 45 List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> 46 List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> 47 List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 48 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> 49 X-List-Received-Date: Thu, 06 Sep 2018 23:23:27 -0000 50 51 Hi Jonas, 52 53 Great to see progress in this area. I have quite a few comments. 54 55 Post-quantum key exchange 56 ========================= 57 I think that's overkill. Bitcoin has huge problems in the presence of a quantum computer, and the 58 confidentiality of the P2P messages is the most minor one. If there is a quantum computer and 59 Bitcoin remains in its current form, then people should probably stop using it. 60 61 Now you can argue that the attacker is storing encrypted traffic today to decrypt it later. Sure, 62 but if that's your threat model then Bitcoin is probably not the right tool for you. (And if 63 you insist that Bitcoin is the right tool, then you can and probably should use it over Tor 64 anyway.) Given the fact that essentially all information in Bitcoin will be public in some way, 65 there are probably cheaper attacks (MITM, traffic analysis). 66 67 It's not worth the hassle, would hinder adoption, and it has the potential to create a wrong 68 impression of "bulletproof" security. Even worse, there will be too many people that will suddenly 69 assume that Bitcoin is post-quantum secure. 70 71 Key exchange indistinguishable from random 72 ========================================== 73 I would rather love to see a simple ECDH key exchange as currently used but with an encoding of 74 public key that provides indistinguishability from random bitstrings. "Elligator" does not work 75 but "Elligator Squared" [1] does the job for secp256k1 -- it just doubles the size of the public 76 key. Together with the encrypted packet lengths, the entire data stream looks like random then, 77 which is pretty useful against censorship resistance for example. (The only exception is that the 78 stream will never start with the magic bytes.) 79 80 Key derivation 81 ============== 82 The key derivation can be improved. It should include each peer's understanding of its role, 83 i.e., requester (or "initiator" is the more common term) or responder. At the moment, an attacker 84 can create a situation where two peers think they're in the same session (with the same session 85 id) but they're actually not. Also, it's possible for an attacker to rerandomize the public keys. 86 That's nothing bad by itself but anything which restricts the flexibility of the attacker without 87 adding complexity is a good idea. Something like 88 "salt = BitcoinSharedSecret||INITIATOR_PUBKEY||RESPONDER_PUBKEY" should just avoid this issue. 89 90 Re-keying 91 ========= 92 The problem with signalling re-keying in the length field is that the length field is not covered 93 by the MAC. So the attacker can flip the signalling bit. The resulting protocol is probably still 94 secure but the malleability is certainly not desirable. 95 96 Deterministic rekeying rules may be better. Otherwise there will be implementations that rekey 97 every 10 seconds and implementations that just don't rekey at all (rendering the 10 s rekeying 98 interval in the opposite direction useless). Different policies also make it possible to 99 fingerprint implementations. Another problem is that people will set their policies arbitrarily. 100 What's better: 5 min or 30 min? I don't know, but both are reasonable choices. (Thats's very much 101 like discussions about ciphers... What's better AES-GCM or ChaCha20/Poly1305? I don't know, but 102 again both are reasonable choices.) 103 104 Symmetric crypto 105 ================ 106 You call it chacha20-poly1305@bitcoin but what's the difference to the openssh then? Is the 107 idea to save a call to chacha here as you mentioned? 108 109 I didn't think about this in detail: maybe there are a few meaningful cases where padding could 110 hide the message length without too much overhead. (I'm not convinced, just a random thought.) 111 112 Misc 113 ==== 114 "The ID/string mapping is a peer to peer arrangement and MAY be negotiated between the 115 requesting and responding peer." I think that's overly complicated. I suggest it should just be 116 written in stone, again to avoid complexity and to avoid fingerprinting. New implementations are 117 necessary anyway, so maybe just use IDs for anything? ASCII is nice if you want to debug your code 118 or some random network failure but that's hard anyway when encryption is used. 119 120 In general, the entire thing is a little bit underspecified. (I'm aware it's just a draft.) 121 A few examples: 122 - What should a peer do if the MAC verification fails? 123 - What should a peer do if it receives an even key? 124 - "Processing the message before the authentication succeeds (MAC verified) MUST not be done." 125 That should also apply to the ciphertext. (Or: What is a "message"?). It may be a good idea to 126 to refer to the openssh document or steal from it; it does a pretty good job. 127 - "Both peers MUST keep track of the message sequence number (uint32) of sent and received 128 messages for building a 64-bit symmetric cipher IV." I think you mean nonce when you say IV? 129 - What is the initial value of the sequence number? 130 - How is a 64-bit nonce formed from one (two?) uint32? 131 - What if the uint32 overflows? 132 - "Re-Keying interval is a peer policy with a minimum timespan of 10 seconds." What if I receive 133 too many re-keying requests? Nothing or should I raise the DoS score? 134 - "The Re-Keying must be done after every 1GB of data sent or received" Hm, every peer updates its 135 own sending key, so this should just read "sent" instead of "sent or received"? 136 137 Pseudocode could probably help here. 138 139 [1] https://eprint.iacr.org/2014/043.pdf 140 141