From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org, Manuel Costa <manecosta@gmail.com>,
 Prayank <prayank@tutanota.de>
Date: Sun, 3 Oct 2021 21:33:43 +0000
User-Agent: KMail/1.9.10
References: <MkZx3Hv--3-2@tutanota.de> <Ml-IIuL--3-2@tutanota.de>
 <CAAxiurb1_-p2yO8183MvB2x_i9H+WAo9t0RH85faRrrKz9YxGg@mail.gmail.com>
In-Reply-To: <CAAxiurb1_-p2yO8183MvB2x_i9H+WAo9t0RH85faRrrKz9YxGg@mail.gmail.com>
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
Precedence: list

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 <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 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