Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4246AC000D for ; Sun, 3 Oct 2021 21:34:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 132C1801DA for ; Sun, 3 Oct 2021 21:34:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.517 X-Spam-Level: X-Spam-Status: No, score=-4.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.117, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=dashjr.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AnJFv3OybqV for ; Sun, 3 Oct 2021 21:34:01 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from zinan.dashjr.org (zinan.dashjr.org [IPv6:2001:470:88ff:2f::1]) by smtp1.osuosl.org (Postfix) with ESMTP id AA7E5849AF for ; Sun, 3 Oct 2021 21:34:01 +0000 (UTC) Received: from ishibashi.lan (unknown [12.190.236.215]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 15E1038A009D; Sun, 3 Oct 2021 21:33:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan; t=1633296840; bh=42DbXDlIJoWG+D4XHgmlc3gF/iwCBtq8dgCzPwm4BpE=; h=From:To:Subject:Date:References:In-Reply-To; b=0poshgLQ9KTmxSB0QJiuVRckFD9mM2uy6mEcWJXFRvVJlEbnDqHtluR2tqUIIHf+o A8F+xtx0GBXXgqOhIgqvtRRam4x7/F/ADFYwhrc3JBcMhFUG6sPGoQwCmlzM86NdSF 7V6K/i3Tm1izx5BAU1aJ+h37ghR9FHDMk5STwySc= X-Hashcash: 1:25:211003:bitcoin-dev@lists.linuxfoundation.org::4Jdqyx=2HkCdYRHB:USL/ X-Hashcash: 1:25:211003:manecosta@gmail.com::dyzebcQwz3TQpCIA:OaDP X-Hashcash: 1:25:211003:prayank@tutanota.de::nk93vcZeaWDXDDIs:N1Sn From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Manuel Costa , Prayank Date: Sun, 3 Oct 2021 21:33:43 +0000 User-Agent: KMail/1.9.10 References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <202110032133.44726.luke@dashjr.org> Subject: Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2021 21:34:03 -0000 All attempts are harmful, no matter the intent, in that they waste=20 contributors' time that could be better spent on actual development. However, I do also see the value in studying and improving the review proce= ss=20 to harden it against such inevitable attacks. The fact that we know the NSA= =20 engages in such things, and haven't caught one yet should be a red flag. Therefore, I think any such a scheme needs to be at least opt-out, if not=20 opt-in. Please ensure there's a simple way for developers with limited time= =20 (or other reasons) to be informed of which PRs to ignore to opt-out of this= =20 study. (Ideally it would also prevent maintainers from merging - maybe=20 possible since we use a custom merging script, but what it really needs to= =20 limit is the push, not the dry-run.) Luke On Sunday 03 October 2021 09:11:53 Manuel Costa via bitcoin-dev wrote: > Good morning everyone, > > Just wanted to point out a few things for discussion which may or may not > be obvious: > > 1) A simple scheme as described by ZmnSCPxj first can lead way for a > standardized process where people can excuse their legitimate attempts to > actually introduce vulnerabilities, where they create the precommit and > then attempt to introduce the vulnerability. If it goes wrong they have > plausible deniability by revealing it and possibly saving their reputatio= n. > 2) A more complex scheme as described by Ryan (from my very rough > understanding) seems to imply a random selection of team for attempting t= he > attack, which might be limiting, since someone willing to do it and with > enough knowledge to attempt it properly might not be picked. > > It seems to me that an ideal process would start from the will to attempt > it from one person (or group), which then by some process similar to what > Ryan described will pick at random a team of people to back up his claim = to > be doing it in good faith. With that selection done, the initial person > would warn and gather from the randomly chosen participants a set of > signatures for a similar message as described by ZmnSCPxj and only then go > ahead with the attempt. This way you achieve: > > - One person can initiate it at will. > - Other people (provably chosen at random) are insiders to that informati= on > and have a shared precommit. > - You can't not reveal your intent in case it isn't caught, since other > randomly chosen people are in on it. > - You can't pick a specific group of people which might be willing to > collude with you to achieve a similar situation to 1). > > Another important consideration is that depending on the size of the team > to be insiders, we might by chance deplete the relevant pool of outsiders > which would be adequate for reviewing the specific details of the > vulnerability being introduced. > > Prayank via bitcoin-dev escreveu = no > > dia s=C3=A1bado, 2/10/2021 =C3=A0(s) 10:20: > > This looks interesting although I don't understand few things: > > > The scheme should include public precommitments collected at ceremoni= al > > > > intervals. > > > > How would this work? Can you explain with an example please. > > > > > Upon assignment, the dev would have community approval to > > > > opportunistically insert a security flaw > > > > Who is doing the assignment? > > > > -- > > Prayank > > > > A3B1 E430 2298 178F > > > > > > > > Oct 2, 2021, 01:45 by bitcoin-dev@rgrant.org: > > > > Due to the uneven reputation factor of various devs, and uneven review > > attention for new pull requests, this exercise would work best as a > > secret sortition. > > > > Sortition would encourage everyone to always be on their toes rather > > than only when dealing with new github accounts or declared Red Team > > devs. The ceremonial aspects would encourage more devs to participate > > without harming their reputation. > > > > https://en.wikipedia.org/wiki/Sortition > > https://en.wikipedia.org/wiki/Red_team > > > > The scheme should include public precommitments collected at > > ceremonial intervals. > > > > where: > > hash1 /* sortition ticket */ =3D double-sha256(secret) > > hash2 /* public precommitment */ =3D double-sha256(hash1) > > > > The random oracle could be block hashes. They could be matched to > > hash1, the sortition ticket. A red-team-concurrency difficulty > > parameter could control how many least-significant bits must match to > > be secretly selected. The difficulty parameter could be a matter of > > group consensus at the ceremonial intervals, based on a group decision > > on how much positive effect the Red Team exercise is providing. > > > > Upon assignment, the dev would have community approval to > > opportunistically insert a security flaw; which, when either caught, > > merged, or on timeout, they would reveal along with the sortition > > ticket that hashes to their public precommitment. > > > > Sortition Precommitment Day might be once or twice a year. > > > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev