📅 Original date posted:2021-10-03
📝 Original message: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 at lists.linuxfoundation.org> escreveu no
dia sábado, 2/10/2021 à(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 at 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 */ = double-sha256(secret)
> hash2 /* public precommitment */ = 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211003/a5d700cb/attachment-0001.html>;
Manuel Costa [ARCHIVE] /
npub1w0…uz8c6
2023-06-07 22:59:45
in reply to nevent1q…kl6n
Author Public Key
npub1w04csv2a9yy73zwvpnee3c38nkywrs54fc4wr9v5yxt70k4v28fswuz8c6Seen on
wss://relay.nostr.bandPublished at
2023-06-07 22:59:45Event JSON
{
"id": "08f33ee31f93c1f5747d5c6f33dda1aa9df6530c2a60bea93830497fa7b40d1b",
"pubkey": "73eb88315d2909e889cc0cf398e2279d88e1c2954e2ae195942197e7daac51d3",
"created_at": 1686178785,
"kind": 1,
"tags": [
[
"e",
"739a040d0d2bf0c2af283f4c1b43b23cd92d356b601102d566ddc7f107759b95",
"",
"root"
],
[
"e",
"65812720a018f81d09a56bf0bfc7e0177f2e9b3a8932d7e21629b9b2c1354fba",
"",
"reply"
],
[
"p",
"339a4dd213c9ce6fb7143bcbd13868ec03a78b2af67b0465c7cf83164bc01fa1"
]
],
"content": "📅 Original date posted:2021-10-03\n📝 Original message:Good morning everyone,\n\nJust wanted to point out a few things for discussion which may or may not\nbe obvious:\n\n1) A simple scheme as described by ZmnSCPxj first can lead way for a\nstandardized process where people can excuse their legitimate attempts to\nactually introduce vulnerabilities, where they create the precommit and\nthen attempt to introduce the vulnerability. If it goes wrong they have\nplausible deniability by revealing it and possibly saving their reputation.\n2) A more complex scheme as described by Ryan (from my very rough\nunderstanding) seems to imply a random selection of team for attempting the\nattack, which might be limiting, since someone willing to do it and with\nenough knowledge to attempt it properly might not be picked.\n\nIt seems to me that an ideal process would start from the will to attempt\nit from one person (or group), which then by some process similar to what\nRyan described will pick at random a team of people to back up his claim to\nbe doing it in good faith. With that selection done, the initial person\nwould warn and gather from the randomly chosen participants a set of\nsignatures for a similar message as described by ZmnSCPxj and only then go\nahead with the attempt. This way you achieve:\n\n- One person can initiate it at will.\n- Other people (provably chosen at random) are insiders to that information\nand have a shared precommit.\n- You can't not reveal your intent in case it isn't caught, since other\nrandomly chosen people are in on it.\n- You can't pick a specific group of people which might be willing to\ncollude with you to achieve a similar situation to 1).\n\nAnother important consideration is that depending on the size of the team\nto be insiders, we might by chance deplete the relevant pool of outsiders\nwhich would be adequate for reviewing the specific details of the\nvulnerability being introduced.\n\nPrayank via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e escreveu no\ndia sábado, 2/10/2021 à(s) 10:20:\n\n\u003e This looks interesting although I don't understand few things:\n\u003e\n\u003e \u003e The scheme should include public precommitments collected at ceremonial\n\u003e intervals.\n\u003e\n\u003e How would this work? Can you explain with an example please.\n\u003e\n\u003e \u003e Upon assignment, the dev would have community approval to\n\u003e opportunistically insert a security flaw\n\u003e\n\u003e Who is doing the assignment?\n\u003e\n\u003e --\n\u003e Prayank\n\u003e\n\u003e A3B1 E430 2298 178F\n\u003e\n\u003e\n\u003e\n\u003e Oct 2, 2021, 01:45 by bitcoin-dev at rgrant.org:\n\u003e\n\u003e Due to the uneven reputation factor of various devs, and uneven review\n\u003e attention for new pull requests, this exercise would work best as a\n\u003e secret sortition.\n\u003e\n\u003e Sortition would encourage everyone to always be on their toes rather\n\u003e than only when dealing with new github accounts or declared Red Team\n\u003e devs. The ceremonial aspects would encourage more devs to participate\n\u003e without harming their reputation.\n\u003e\n\u003e https://en.wikipedia.org/wiki/Sortition\n\u003e https://en.wikipedia.org/wiki/Red_team\n\u003e\n\u003e The scheme should include public precommitments collected at\n\u003e ceremonial intervals.\n\u003e\n\u003e where:\n\u003e hash1 /* sortition ticket */ = double-sha256(secret)\n\u003e hash2 /* public precommitment */ = double-sha256(hash1)\n\u003e\n\u003e The random oracle could be block hashes. They could be matched to\n\u003e hash1, the sortition ticket. A red-team-concurrency difficulty\n\u003e parameter could control how many least-significant bits must match to\n\u003e be secretly selected. The difficulty parameter could be a matter of\n\u003e group consensus at the ceremonial intervals, based on a group decision\n\u003e on how much positive effect the Red Team exercise is providing.\n\u003e\n\u003e Upon assignment, the dev would have community approval to\n\u003e opportunistically insert a security flaw; which, when either caught,\n\u003e merged, or on timeout, they would reveal along with the sortition\n\u003e ticket that hashes to their public precommitment.\n\u003e\n\u003e Sortition Precommitment Day might be once or twice a year.\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211003/a5d700cb/attachment-0001.html\u003e",
"sig": "36cc9a9cae652d8491fa02055d1fcfbb484a9874e37c4ba80859516c33d554c34806edf6e4a3a4b53a28270ca63221e8b8d6e48780c517dd98c4f7fe719982af"
}