diff options
| author | Gregory Maxwell <greg@xiph.org> | 2018-09-07 02:31:15 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-09-07 02:31:33 +0000 |
| commit | 0438b1f946469c3d416926383113b5d3929c2e35 (patch) | |
| tree | 4666ad1c07e76deff14e4d0d2f8c4b3c23dc3be7 | |
| parent | eeda8c92660a69c57c9a392da6fd91c5adf492ba (diff) | |
| download | pi-bitcoindev-0438b1f946469c3d416926383113b5d3929c2e35.tar.gz pi-bitcoindev-0438b1f946469c3d416926383113b5d3929c2e35.zip | |
Re: [bitcoin-dev] Overhauled BIP151
| -rw-r--r-- | 96/0b0fb2435cf1a3fc21da4e84c13e86d87a27d2 | 262 |
1 files changed, 262 insertions, 0 deletions
diff --git a/96/0b0fb2435cf1a3fc21da4e84c13e86d87a27d2 b/96/0b0fb2435cf1a3fc21da4e84c13e86d87a27d2 new file mode 100644 index 000000000..63d8213e6 --- /dev/null +++ b/96/0b0fb2435cf1a3fc21da4e84c13e86d87a27d2 @@ -0,0 +1,262 @@ +Return-Path: <gmaxwell@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id EACA4EDA + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 7 Sep 2018 02:31:33 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-ua1-f67.google.com (mail-ua1-f67.google.com + [209.85.222.67]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6D51A7EB + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 7 Sep 2018 02:31:30 +0000 (UTC) +Received: by mail-ua1-f67.google.com with SMTP id r15-v6so10820944uao.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 06 Sep 2018 19:31:30 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=KgBNrwMGlTidaWKGh1UL1/a+ixWoBP7I5cGHzbBgns0=; + b=CfNTpCWAnxrSZ5ltqxVpeE8K6KS5WMxthTlXHwdWu/T5kVZyfm3FFDleJjo4HU0qaP + RmFaYK2nlFlBZmEK2b5IGG7sXub9KBHVoacRHZblq73te4LRmc5X/4Gp3paaG8EqyI3e + Vs5+WBL7s+nEq9KpGOS39wpf0VTJwDu7i1A7euBYDr0ZPsylvM9vTCepxdia2edEi0v7 + OhU8Xl+4K+zIjA6KQVT0Z4Fz3h8eXzz0Ici2oCEySYozUPRs5q16sZwOWUP0dCpC+dZl + UG6TS/6ZpoPosVI8m34UWFY4QIvnGkEOo2HyGEnD48/i3ex1XvCgc+EHqb+yAYRrCU+2 + t1Ag== +X-Gm-Message-State: APzg51AJrWXj2et0g3cr1IP37RV8X0MeJVKwybrxSoYhSXuOUhGvfxkW + nWbtg3bJmUpXhpP8ZpM4bggzO2HBYXM1aVJpHNZ61O0+ +X-Google-Smtp-Source: ANB0VdZw90FB/XfnfKTmQKEj+vLbnUvKp4QHO2ASyVNIkakv7Bt0T4N8rVNT9V1MCpYNxi4Z2am2k6PrMv3IVpY0oqU= +X-Received: by 2002:a67:eb01:: with SMTP id a1-v6mr2054552vso.13.1536287489394; + Thu, 06 Sep 2018 19:31:29 -0700 (PDT) +MIME-Version: 1.0 +References: <640D015D-3DDB-43C4-9752-96ADABF64C91@jonasschnelli.ch> + <061aa38d8ceeb6caaae19d7c86e435a5f86b293b.camel@timruffing.de> +In-Reply-To: <061aa38d8ceeb6caaae19d7c86e435a5f86b293b.camel@timruffing.de> +From: Gregory Maxwell <greg@xiph.org> +Date: Fri, 7 Sep 2018 02:31:15 +0000 +Message-ID: <CAAS2fgQPkR63FmUyP8mAkmv4D-ttJ1C3rZismNr9_takBRS1qQ@mail.gmail.com> +To: crypto@timruffing.de, bitcoin-dev@lists.linuxfoundation.org +Content-Type: text/plain; charset="UTF-8" +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, + RCVD_IN_DNSWL_NONE 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: Fri, 07 Sep 2018 13:45:59 +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 <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: Fri, 07 Sep 2018 02:31:34 -0000 + +On Thu, Sep 6, 2018 at 11:33 PM Tim Ruffing via bitcoin-dev +<bitcoin-dev@lists.linuxfoundation.org> wrote: +> Now you can argue that the attacker is storing encrypted traffic today to decrypt it later. + +That is the argument. We know for that state level parties are storing +unimaginable amounts of data for future decryption, that threat isn't +theoretical. + +> Sure, +> but if that's your threat model then Bitcoin is probably not the right tool for you. (And if + +Why not? + +> you insist that Bitcoin is the right tool, then you can and probably should use it over Tor +> anyway.) + +Currently, Tor provides _no confidentiality at all_ in that threat +model. Part of why I think this enhancement is interesting is because +without it BIP151 doesn't actually add anything for those p2p +connections running over Tor, but with it -- it at least adds some +long term confidentiality hedge. + +> It's not worth the hassle, would hinder adoption, + +Why do you say this? + +> impression of "bulletproof" security. Even worse, there will be too many people that will suddenly +> assume that Bitcoin is post-quantum secure. + +People already make that claim with respect to public key hashing. I +don't think "we shouldn't improve security because someone will +mistake an improvement for perfection" is an an especially interesting +argument. + +> 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 + +Here is where I turn the argument around on you: This requires +writing a non-trivial amount of moderately complex new cryptographic +code (which is not the case for PQ schemes-- that merely requires +dropping in pre-existing code) and yet I am not aware of any attack +model that this which would any improvement in actually delivered +security: Bitcoin traffic is _trivially_ identifiable by its traffic +patterns. + +(Blockstream previously wrote the SW forward transform for asset +generation, but this requires the inverse too, as well as glue code. +It also isn't clear to me if it's possible to make this construction +constant time, which would be okay for BIP151 purposes but if we +wanted to have a generic uniform encoder in libsecp256k1 I think we'd +prefer it be constant time? maybe?) + +The scheme in the BIP thus far achieves the property that there are no +fixed bytes for brain-dead byte matching DPI traffic filtering or +anti-virus to match on (or accidentally false positive on). AV false +positives are already an existing problem with the current protocol +and any fixed bytes in the communication are at risk for false +positives or targeted filtering. And achieving that property +requires basically nothing: a test for the first byte of a generated +serialized pubkey and a negate on the private key if it was wrong. + +> key. Together with the encrypted packet lengths, the entire data stream looks like random then, + +No, it doesn't-- due to traffic analysis. Including, for example, the +pattern that 64-bytes must be sent in each direction, before further +data continues, bursts of traffic coinciding with blocks newly found +on the network, etc. + +I don't believe that indistinguishable keys are actually useful +outside of the context of things like stegnographic embedding-- cases +where protocol 'metadata' doesn't tell you that a key is there +regardless. + +I suppose if the code already existed to do it I might as well go +"okay, sure why not", it's not going to harm anything (the added +computation time to generate the uniform encoding would probably be no +more than a 10% slowdown). I wouldn't argue against it on the basis +that someone might believe it resulted in anti-censorship properties +that it doesn't have ... even though it's clearly the case... because +I categorically reject that form of argument. :) + +I think your view on the two distinctive proposals is askew: PQ +agreement has a clear benefit under a plausible threat model and is +quite easy to implement... while uniform encoding is somewhat harder +to implement (though admittedly not very hard) but doesn't appear to +provide a concrete benefit under any threat model that I'm currently +aware of... + +> 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. + +I also prefer the contributory key model, but Pieter proved me on IRC +last week that the attack form that I was concerned about was not +possible. + +Do you actually have an attack in mind that you can spell out here? I +don't see a harm in changing that, but given that I'd already twice +talked myself out of proposing the same thing, I'd like to understand +if I'm missing something. :) + +> Re-keying +> ========= +> The problem with signalling re-keying in the length field is that the length field is not covered +> by the MAC. + +It's AAD data in the mac, unless I misunderstand the protocol. + +> Deterministic rekeying rules may be better. Otherwise there will be implementations that rekey +> every 10 seconds + +That would be pretty harmless, since the rekeying operation costs +similar to one message decryption. + +> and implementations that just don't rekey at all (rendering the 10 s rekeying +> interval in the opposite direction useless). + +The protocol requires rekeying at least after a given amount of data +is transmitted. Peers that violate that can be disconnected. But it +could be unfortunately infrequent. + +> Different policies also make it possible to +> fingerprint implementations. + +I agree that is a good point. + +Personally I'd prefer that we used a ciphersuite that effectively +"rekeyed" every message-- along the lines of the constructions +described https://blog.cr.yp.to/20170723-random.html Unfortunately I +was unable to find _any_ well analyized authenticated encryption mode +that has the fast erasure property. It's too bad because it would be +trivial to adhoc one (e.g. use the extra 32 bytes from the poly1305 +chacha run to update the keys for the next message). + +> What's better: 5 min or 30 min? I don't know, but both are reasonable choices. (Thats's very much + +It doesn't much matter, except for fingerprinting reasons. + +> like discussions about ciphers... What's better AES-GCM or ChaCha20/Poly1305? I don't know, but +> again both are reasonable choices.) + +Here we have a very clear motiviation. On devices without hardware +AES/clmul constant time AES-GCM is _terribly slow_ compared to +ChaCha20/Poly1305. Performance on the slowest devices is where the +the ones where the ciphersuite choice likely matters at all (because +it could actually make a meaningful difference in their system's +ability to keep up), and the slowest devices that I'm aware of users +commonly using are also devices without good AES-GCM performance. +Unfortunately. + +On fast desktop hardware the performance of AES-GCM and +ChaCha20/Poly1305 is also fairly close. + +So when it matters, chacha20/poly1305 is higher performance by a wide +margin. (Too bad, because otherwise I'd much rather use AES-GCM) + +> 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.) + +This can be done at the message level. E.g. new TX messages that round +tx sizes up to the next multiple. I don't think useful low overhead +padding is otherwise possible. + + +> written in stone, again to avoid complexity and to avoid fingerprinting. + +Writing things in stone is a great way to never finish a protocol. +Right now we know we have new upcoming proposals for messages where +the overhead matters, e.g. we need a replacement addr message ASAP, +and there is ongoing work for transaction relay that would also +benefit from low overhead. + +The norm in Bitcoin is to ignore messages you don't know how to parse +anyways, so there is no complexity that arises from "may negotiate" +itself-- only from actually making use of that possibility in the +future, so the merits of any particular usage could be decided when +something wants to actually use it. The purpose of pointing out "may +negotiate" is, I think, primarily to avoid a debate about who would +assign numbers from this limited space in the future-- and the answer +just is that they're implementation defined (e.g. by the BIPs using +them). + +> 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. + +Right, encryption kills external analysers in any case. It's also easy +to just logprintf traffic (this is open source software after all), +which doesn't have a decoding problem. + +> - "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"? + +I think it says 'received there' mostly because it's implicitly +telling you that you can hang up on someone who violates it. I agree +it would be more consistent to express it sending side there. + |