diff options
| author | Manuel Costa <manecosta@gmail.com> | 2021-10-03 10:11:53 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-10-03 09:12:07 +0000 |
| commit | c6536ceee23a0176e56ff25541419b143d51249c (patch) | |
| tree | 94a981d2c0c5a98ccd1889befafb5eae35cb3ee2 | |
| parent | 2eb88bb7366606deb6d0c896ce0dc4e3ee93b796 (diff) | |
| download | pi-bitcoindev-c6536ceee23a0176e56ff25541419b143d51249c.tar.gz pi-bitcoindev-c6536ceee23a0176e56ff25541419b143d51249c.zip | |
Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects
| -rw-r--r-- | d1/493a5756bf4e47b7ce2e146947308664186089 | 292 |
1 files changed, 292 insertions, 0 deletions
diff --git a/d1/493a5756bf4e47b7ce2e146947308664186089 b/d1/493a5756bf4e47b7ce2e146947308664186089 new file mode 100644 index 000000000..8f3420e7b --- /dev/null +++ b/d1/493a5756bf4e47b7ce2e146947308664186089 @@ -0,0 +1,292 @@ +Return-Path: <manecosta@gmail.com> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 079CFC000D + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 3 Oct 2021 09:12:07 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id D4E584019B + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 3 Oct 2021 09:12:06 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.098 +X-Spam-Level: +X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Authentication-Results: smtp2.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.com +Received: from smtp2.osuosl.org ([127.0.0.1]) + by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id AX06t33maJlg + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 3 Oct 2021 09:12:05 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com + [IPv6:2607:f8b0:4864:20::1035]) + by smtp2.osuosl.org (Postfix) with ESMTPS id 55A51400F3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 3 Oct 2021 09:12:05 +0000 (UTC) +Received: by mail-pj1-x1035.google.com with SMTP id + d13-20020a17090ad3cd00b0019e746f7bd4so1765241pjw.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 03 Oct 2021 02:12:05 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=xcfaHw8Zq6xMkPp4ocIpfaz8je6o+S23DvYEI6jIy18=; + b=M63VAtIXrG6s/73mWAmwDI6to5gj2D5m0cd2+cOaVutdJTbCCHjgdk1QXbtvaf8fwc + marK2Bdw75aaNgD8bsN+MNPe+3dKllKwca5W7Iju8wKdJCwQtdJuddKEKaeDq5Ld2smU + TJj/8g8rN4OFszqKUPHFCrVjC+rNIo0n20sHx+ZTpbew5nfw9Aza40DFVQPoLDTNrki8 + PER4GVSsTN76EAQipEmPbruC6IeHPne6wNx7Ac4HDyEuBrkTfAyZj1uKjdBMCA7qxjQ9 + hJpSH1f2QZ3rOp8rxYLIdDrBxVyrhfJ6xoA/CzuK+C9FWrdIO1AeWEffizLLJS7V5YOE + 0lPQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=xcfaHw8Zq6xMkPp4ocIpfaz8je6o+S23DvYEI6jIy18=; + b=Gry4JPQZCr/IcYLNwBGQYP3vkGZ9N7sSGsPRnPlCQkPfr3DpkpwB+8vE8hs369bB06 + DSrZZQK46N6B33GixK1a+sV1GZlZ1ST5hXjzjUgqysaayT7kKv6YCAV/3VMtU8nNL1vL + sViQ5tYYf6oYQqxDoy5xIszX2GuJv56qJRCUJhroquyLxzUw0g0yhrUL8th0cQiQQWAC + N/pWxnGxc0IiVeUhxCs2VEvG0tLcsjgzWM3egP4tiqX0QVLh/T9J6kWoJL2Rv3SHe9Oo + ClmWuKz2WaUcH0jBmc8URyAudQQFDnqTWyQO6DWu/+DcdsgzSE5+KFaaVgUFrilhA5w1 + SP6g== +X-Gm-Message-State: AOAM533av6q0RW37iOPFgA/3wvTQhKQhcx827e2AnFehO9nZBzHF+wZm + l0eKEqLNBBLQI9cOpTL23ouC2+GPTykxhiSKAmFYguRcLxc= +X-Google-Smtp-Source: ABdhPJxXj5O9OTeLtieXAY9K0u6eLfRJ2GSatwXm0g1AazNeQeyrsX8AKex2h1oZGKkE/LFP2TRRkbw9sSdM9yU0jmQ= +X-Received: by 2002:a17:90a:af92:: with SMTP id + w18mr23558168pjq.98.1633252324703; + Sun, 03 Oct 2021 02:12:04 -0700 (PDT) +MIME-Version: 1.0 +References: <MkZx3Hv--3-2@tutanota.de> + <yp9mJ2Poc_Ce91RkrhjnTA3UPvdh0wUyw2QhRPZEyO3gPHZPhmnhqER_4b7ChvmRh8GcYVPEkoud6vamJ9lGlQPi-POF-kyimBWNHz2RH3A=@protonmail.com> + <MkdYcV9--3-2@tutanota.de> + <CAPv7TjbvRE-b33MeYucUfr6CTooCRSH42hwSn5dMiJ4LODATRQ@mail.gmail.com> + <MktnWM7--3-2@tutanota.de> + <qNjz-H23x07OJjnf5Try4Qp8l5s23SQxhEE8yAfNbrniN34u2vM72FVFSDJxHg4HNTL8tdcm-KKT8h6XVRwOwN0ZmckxzWiMlNFmLbMNuHc=@protonmail.com> + <MkwZGYl--7-2@tutanota.de> + <CAMnpzfrNZ0vpiMVoH=0KW9jy1-vppudX3D7Z+aXpSp4h_7s=zw@mail.gmail.com> + <Ml-IIuL--3-2@tutanota.de> +In-Reply-To: <Ml-IIuL--3-2@tutanota.de> +From: Manuel Costa <manecosta@gmail.com> +Date: Sun, 3 Oct 2021 10:11:53 +0100 +Message-ID: <CAAxiurb1_-p2yO8183MvB2x_i9H+WAo9t0RH85faRrrKz9YxGg@mail.gmail.com> +To: Prayank <prayank@tutanota.de>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000a484f005cd6f3041" +X-Mailman-Approved-At: Sun, 03 Oct 2021 15:08:45 +0000 +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 <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: Sun, 03 Oct 2021 09:12:07 -0000 + +--000000000000a484f005cd6f3041 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +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 reputation. +2) A more complex scheme as described by Ryan (from my very rough +understanding) seems to imply a random selection of team for attempting the +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 information +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 <bitcoin-dev@lists.linuxfoundation.org> 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 ceremonial +> 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 +> + +--000000000000a484f005cd6f3041 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Good morning everyone,<d= +iv><br></div><div>Just wanted to point out a few things for discussion whic= +h may or may not be obvious:</div><div><br></div><div>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 vulnerabi= +lities, where they create the precommit and then attempt to introduce the v= +ulnerability. If it goes wrong they have plausible deniability by revealing= + it and possibly saving their reputation.</div><div>2) A more complex schem= +e as described by Ryan (from my very rough understanding) seems to imply a = +random selection of team for attempting the attack, which might be limiting= +, since someone willing to do it and with enough knowledge to attempt it pr= +operly might not be picked.<br><br>It seems to me that an ideal process wou= +ld 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 sele= +ction done, the initial person would warn and gather from the randomly chos= +en participants a set of signatures for a similar message as described by= +=C2=A0ZmnSCPxj and only then go ahead with the attempt. This way you achiev= +e:<br><br>- One person can initiate it at will.<br>- Other people (provably= + chosen at random) are insiders to that information and have a shared preco= +mmit.<br>- You can't not reveal your intent in case it isn't caught= +, since other randomly chosen people are in on it.<br>- You can't pick = +a specific group of people which might be willing to collude with you to ac= +hieve a similar situation to 1).</div><div><br></div><div>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 adeq= +uate for reviewing the specific details of the vulnerability being introduc= +ed.</div></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" = +class=3D"gmail_attr">Prayank via bitcoin-dev <<a href=3D"mailto:bitcoin-= +dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>>= +; escreveu no dia s=C3=A1bado, 2/10/2021 =C3=A0(s) 10:20:<br></div><blockqu= +ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px= + solid rgb(204,204,204);padding-left:1ex"> + =20 + =20 + =20 + <div> +<div>This looks interesting although I don't understand few things:<br>= +</div><div dir=3D"auto"><br></div><div dir=3D"auto">> The scheme should = +include public precommitments collected at ceremonial intervals.<br></div><= +div dir=3D"auto"><br></div><div dir=3D"auto">How would this work? Can you e= +xplain with an example please.<br></div><div dir=3D"auto"><br></div><div di= +r=3D"auto">> Upon assignment, the dev would have community approval to o= +pportunistically insert a security flaw<br></div><div dir=3D"auto"><br></di= +v><div dir=3D"auto">Who is doing the assignment?<br></div><div><br></div><d= +iv>-- <br></div><div>Prayank<br></div><div><br></div><div dir=3D"auto">A3B1= + E430 2298 178F<br></div><div><br></div><div><br></div><div><br></div><div>= +Oct 2, 2021, 01:45 by <a href=3D"mailto:bitcoin-dev@rgrant.org" target=3D"_= +blank">bitcoin-dev@rgrant.org</a>:<br></div><blockquote style=3D"border-lef= +t:1px solid rgb(147,163,184);padding-left:10px;margin-left:5px"><div>Due to= + the uneven reputation factor of various devs, and uneven review<br></div><= +div>attention for new pull requests, this exercise would work best as a<br>= +</div><div>secret sortition.<br></div><div><br></div><div>Sortition would e= +ncourage everyone to always be on their toes rather<br></div><div>than only= + when dealing with new github accounts or declared Red Team<br></div><div>d= +evs. The ceremonial aspects would encourage more devs to participate<br></= +div><div>without harming their reputation.<br></div><div><br></div><div> <a= + href=3D"https://en.wikipedia.org/wiki/Sortition" target=3D"_blank">https:/= +/en.wikipedia.org/wiki/Sortition</a><br></div><div> <a href=3D"https://en.w= +ikipedia.org/wiki/Red_team" target=3D"_blank">https://en.wikipedia.org/wiki= +/Red_team</a><br></div><div><br></div><div>The scheme should include public= + precommitments collected at<br></div><div>ceremonial intervals.<br></div><= +div><br></div><div>where:<br></div><div> hash1 /* sortition ticket */ = +=3D double-sha256(secret)<br></div><div> hash2 /* public precommitment */ = +=3D double-sha256(hash1)<br></div><div><br></div><div>The random oracle cou= +ld be block hashes. They could be matched to<br></div><div>hash1, the sort= +ition ticket. A red-team-concurrency difficulty<br></div><div>parameter co= +uld control how many least-significant bits must match to<br></div><div>be = +secretly selected. The difficulty parameter could be a matter of<br></div>= +<div>group consensus at the ceremonial intervals, based on a group decision= +<br></div><div>on how much positive effect the Red Team exercise is providi= +ng.<br></div><div><br></div><div>Upon assignment, the dev would have commun= +ity approval to<br></div><div>opportunistically insert a security flaw; whi= +ch, when either caught,<br></div><div>merged, or on timeout, they would rev= +eal along with the sortition<br></div><div>ticket that hashes to their publ= +ic precommitment.<br></div><div><br></div><div>Sortition Precommitment Day = +might be once or twice a year.<br></div></blockquote><div dir=3D"auto"><br>= +</div> </div> + +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--000000000000a484f005cd6f3041-- + |