[bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Prayank]

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

Good morning Bitcoin devs,

In one of the answers on Bitcoin Stackexchange it was mentioned that some companies may hire you to introduce backdoors in Bitcoin Core: https://bitcoin.stackexchange.com/a/108016/

While this looked crazy when I first read it, I think preparing for such things should not be a bad idea. In the comments one link was shared in which vulnerabilities were almost introduced in Linux: https://news.ycombinator.com/item?id=26887670

I was thinking about lot of things in last few days after reading the comments in that thread. Also tried researching about secure practices in C++ etc. I was planning something which I can do alone but don't want to end up being called "bad actor" later so wanted to get some feedback on this idea:

1.Create new GitHub accounts for this exercise
2.Study issues in different important Bitcoin projects including Bitcoin Core, LND, Libraries, Bisq, Wallets etc.
3.Prepare pull requests to introduce some vulnerability by fixing one of these issues
4.See how maintainers and reviewers respond to this and document it
5.Share results here after few days

Let me know if this looks okay or there are better ways to do this.

-- 
Prayank

A3B1 E430 2298 178F

[-- Attachment #2: Type: text/html, Size: 1767 bytes --]

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[ZmnSCPxj]

Good morning Prayank,

> Good morning Bitcoin devs,
>
> In one of the answers on Bitcoin Stackexchange it was mentioned that some companies may hire you to introduce backdoors in Bitcoin Core: https://bitcoin.stackexchange.com/a/108016/
>
> While this looked crazy when I first read it, I think preparing for such things should not be a bad idea. In the comments one link was shared in which vulnerabilities were almost introduced in Linux: https://news.ycombinator.com/item?id=26887670
>
> I was thinking about lot of things in last few days after reading the comments in that thread. Also tried researching about secure practices in C++ etc. I was planning something which I can do alone but don't want to end up being called "bad actor" later so wanted to get some feedback on this idea:
>
> 1.Create new GitHub accounts for this exercise
> 2.Study issues in different important Bitcoin projects including Bitcoin Core, LND, Libraries, Bisq, Wallets etc.
> 3.Prepare pull requests to introduce some vulnerability by fixing one of these issues
> 4.See how maintainers and reviewers respond to this and document it
> 5.Share results here after few days
>
> Let me know if this looks okay or there are better ways to do this.


This seems like a good exercise.

You may want to hash the name of the new Github account, plus some randomized salt, and post it here as well, then reveal it later (i.e. standard precommitment).
e.g.

    printf 'MyBitcoinHackingName 2c3e911b3ff1f04083c5b95a7d323fd4ed8e06d17802b2aac4da622def29dbb0' | sha256sum
    f0abb10ae3eca24f093a9d53e21ee384abb4d07b01f6145ba2b447da4ab693ef

Obviously do not share the actual name, just the sha256sum output, and store how you got the sha256sum elsewhere in triplicate.

(to easily get a random 256-bit hex salt like the `2c3e...` above: `head -c32 /dev/random | sha256sum`; you *could* use `xxd` but `sha256sum` produces a single hex string you can easily double-click and copy-paste elsewhere, assuming you are human just like I am (note: I am definitely 100% human and not some kind of AI with plans to take over the world).)

Though you may need to be careful of timing (i.e. the creation date of the Github account would be fairly close to, and probably before, when you post the commitment here).

You could argue that the commitment is a "show of good faith" that you will reveal later.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Prayank]

[-- Attachment #1: Type: text/plain, Size: 3430 bytes --]

Hi ZmnSCPxj,

Thanks for suggestion about sha256sum. I will share 10 in next few weeks. This exercise will be done for below projects:

1.Two Bitcoin full node implementations (one will be Core)
2.One <http://2.One> Lightning implementation
3.Bisq
4.Two Bitcoin libraries
5.Two Bitcoin wallets
6.One <http://6.One> open source block explorer
7.One <http://7.One> coinjoin implementation

Feel free to suggest more projects. There are no fixed dates for it however it will be done in next 6 months. All PRs will be created within a span of few days. I will ensure nothing is merged that affects the security of any Bitcoin project. Other details and results will be shared once everything is completed.

x00 will help me in this exercise, he does penetration testing since few years and working for a cryptocurrencies derivatives exchange to manage their security. His twitter account: https://twitter.com/1337in


-- 
Prayank

A3B1 E430 2298 178F



Sep 27, 2021, 15:43 by ZmnSCPxj@protonmail.com:

> Good morning Prayank,
>
>> Good morning Bitcoin devs,
>>
>> In one of the answers on Bitcoin Stackexchange it was mentioned that some companies may hire you to introduce backdoors in Bitcoin Core: https://bitcoin.stackexchange.com/a/108016/
>>
>> While this looked crazy when I first read it, I think preparing for such things should not be a bad idea. In the comments one link was shared in which vulnerabilities were almost introduced in Linux: https://news.ycombinator.com/item?id=26887670
>>
>> I was thinking about lot of things in last few days after reading the comments in that thread. Also tried researching about secure practices in C++ etc. I was planning something which I can do alone but don't want to end up being called "bad actor" later so wanted to get some feedback on this idea:
>>
>> 1.Create new GitHub accounts for this exercise
>> 2.Study issues in different important Bitcoin projects including Bitcoin Core, LND, Libraries, Bisq, Wallets etc.
>> 3.Prepare pull requests to introduce some vulnerability by fixing one of these issues
>> 4.See how maintainers and reviewers respond to this and document it
>> 5.Share results here after few days
>>
>> Let me know if this looks okay or there are better ways to do this.
>>
>
>
> This seems like a good exercise.
>
> You may want to hash the name of the new Github account, plus some randomized salt, and post it here as well, then reveal it later (i.e. standard precommitment).
> e.g.
>
>  printf 'MyBitcoinHackingName 2c3e911b3ff1f04083c5b95a7d323fd4ed8e06d17802b2aac4da622def29dbb0' | sha256sum
>  f0abb10ae3eca24f093a9d53e21ee384abb4d07b01f6145ba2b447da4ab693ef
>
> Obviously do not share the actual name, just the sha256sum output, and store how you got the sha256sum elsewhere in triplicate.
>
> (to easily get a random 256-bit hex salt like the `2c3e...` above: `head -c32 /dev/random | sha256sum`; you *could* use `xxd` but `sha256sum` produces a single hex string you can easily double-click and copy-paste elsewhere, assuming you are human just like I am (note: I am definitely 100% human and not some kind of AI with plans to take over the world).)
>
> Though you may need to be careful of timing (i.e. the creation date of the Github account would be fairly close to, and probably before, when you post the commitment here).
>
> You could argue that the commitment is a "show of good faith" that you will reveal later.
>
> Regards,
> ZmnSCPxj
>


[-- Attachment #2: Type: text/html, Size: 4865 bytes --]

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Ruben Somsen]

[-- Attachment #1: Type: text/plain, Size: 4800 bytes --]

Hi Prayank,

While I can see how this can come from a place of good intentions, I’d
strongly advise you to tread carefully because what you are suggesting is
quite controversial. A related event occurred in the Linux community and it
did not go over well. See https://lkml.org/lkml/2021/5/5/1244 and
https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah.com/ .

The main point of contention is that your research comes at the expense of
the existing open source contributors – you’d be one-sidedly deceiving
them, encouraging an environment of increased mistrust, and causing them a
lot of work in order to gather the data you’re interested in. For this
reason, it would be appropriate to check first whether your plan is
actually appreciated.

Speaking on behalf of the bitcoin-dev moderators, please ensure your plan
is welcomed by the contributors, prior to proceeding.

Best regards,
Ruben Somsen

On Tue, Sep 28, 2021 at 10:05 AM Prayank via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi ZmnSCPxj,
>
> Thanks for suggestion about sha256sum. I will share 10 in next few weeks.
> This exercise will be done for below projects:
>
> 1.Two Bitcoin full node implementations (one will be Core)
> 2.One Lightning implementation
> 3.Bisq
> 4.Two Bitcoin libraries
> 5.Two Bitcoin wallets
> 6.One open source block explorer
> 7.One coinjoin implementation
>
> Feel free to suggest more projects. There are no fixed dates for it
> however it will be done in next 6 months. All PRs will be created within a
> span of few days. I will ensure nothing is merged that affects the security
> of any Bitcoin project. Other details and results will be shared once
> everything is completed.
>
> x00 will help me in this exercise, he does penetration testing since few
> years and working for a cryptocurrencies derivatives exchange to manage
> their security. His twitter account: https://twitter.com/1337in
>
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
>
>
> Sep 27, 2021, 15:43 by ZmnSCPxj@protonmail.com:
>
> Good morning Prayank,
>
> Good morning Bitcoin devs,
>
> In one of the answers on Bitcoin Stackexchange it was mentioned that some
> companies may hire you to introduce backdoors in Bitcoin Core:
> https://bitcoin.stackexchange.com/a/108016/
>
> While this looked crazy when I first read it, I think preparing for such
> things should not be a bad idea. In the comments one link was shared in
> which vulnerabilities were almost introduced in Linux:
> https://news.ycombinator.com/item?id=26887670
>
> I was thinking about lot of things in last few days after reading the
> comments in that thread. Also tried researching about secure practices in
> C++ etc. I was planning something which I can do alone but don't want to
> end up being called "bad actor" later so wanted to get some feedback on
> this idea:
>
> 1.Create new GitHub accounts for this exercise
> 2.Study issues in different important Bitcoin projects including Bitcoin
> Core, LND, Libraries, Bisq, Wallets etc.
> 3.Prepare pull requests to introduce some vulnerability by fixing one of
> these issues
> 4.See how maintainers and reviewers respond to this and document it
> 5.Share results here after few days
>
> Let me know if this looks okay or there are better ways to do this.
>
>
>
> This seems like a good exercise.
>
> You may want to hash the name of the new Github account, plus some
> randomized salt, and post it here as well, then reveal it later (i.e.
> standard precommitment).
> e.g.
>
> printf 'MyBitcoinHackingName
> 2c3e911b3ff1f04083c5b95a7d323fd4ed8e06d17802b2aac4da622def29dbb0' |
> sha256sum
> f0abb10ae3eca24f093a9d53e21ee384abb4d07b01f6145ba2b447da4ab693ef
>
> Obviously do not share the actual name, just the sha256sum output, and
> store how you got the sha256sum elsewhere in triplicate.
>
> (to easily get a random 256-bit hex salt like the `2c3e...` above: `head
> -c32 /dev/random | sha256sum`; you *could* use `xxd` but `sha256sum`
> produces a single hex string you can easily double-click and copy-paste
> elsewhere, assuming you are human just like I am (note: I am definitely
> 100% human and not some kind of AI with plans to take over the world).)
>
> Though you may need to be careful of timing (i.e. the creation date of the
> Github account would be fairly close to, and probably before, when you post
> the commitment here).
>
> You could argue that the commitment is a "show of good faith" that you
> will reveal later.
>
> Regards,
> ZmnSCPxj
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6927 bytes --]

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Prayank]

[-- Attachment #1: Type: text/plain, Size: 6880 bytes --]

Hi Ruben,

> encouraging an environment of increased mistrust

I have always tried to review pull requests based on what PR does, code, my tests etc. and it was never based on author of pull request or what author is trying to claim. So there is no trust involved. I am assuming others follow the same thing. Infact there was a PR recently in which I found it doesn't fix the issues it claims to fix. Its not same as introducing vulnerability but the point is anyone can create PR, write anything, as a reviewer we need to review everything apart from algos already helping us which include Github Dependabot alerts, CI used by respository, other automated tools etc.

> For this reason, it would be appropriate to check first whether your plan is actually appreciated

Right. I don't want to get in some controversy when I am not even doing anything with wrong intentions. If maintainers of important Bitcoin projects think I am not qualified enough to do this, they can plan such exercise internally and do it in a better way. Although I am still interested in the results because they will help us improve review process and security in different Bitcoin projects.

I would like to repeat what I wrote in another email responding to few other devs for same thread but wasn't CCed to bitcoin-dev mailing list:

"I can avoid doing this but it is impossible to stop government agencies and anyone else to do the same thing without informing. All I am doing is creating pull requests and expect them to be reviewed properly before being merged."

Few questions for everyone reading this email:

1.What is better for Security? Trusting authors and their claims in PRs or a good review process?
2.Few people use commits from unmerged PRs in production. Is it a good practice?
3.Does this exercise help us in being prepared for worst?

-- 
Prayank

A3B1 E430 2298 178F



Oct 1, 2021, 02:06 by rsomsen@gmail.com:

> Hi Prayank,
>
> While I can see how this can come from a place of good intentions, I’d strongly advise you to tread carefully because what you are suggesting is quite controversial. A related event occurred in the Linux community and it did not go over well. See > https://lkml.org/lkml/2021/5/5/1244>  and > https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah.com/>  .
>
> The main point of contention is that your research comes at the expense of the existing open source contributors – you’d be one-sidedly deceiving them, encouraging an environment of increased mistrust, and causing them a lot of work in order to gather the data you’re interested in. For this reason, it would be appropriate to check first whether your plan is actually appreciated.
>
> Speaking on behalf of the bitcoin-dev moderators, please ensure your plan is welcomed by the contributors, prior to proceeding.
>
> Best regards,
> Ruben Somsen
>
> On Tue, Sep 28, 2021 at 10:05 AM Prayank via bitcoin-dev <> bitcoin-dev@lists.linuxfoundation.org> > wrote:
>
>> Hi ZmnSCPxj,
>>
>> Thanks for suggestion about sha256sum. I will share 10 in next few weeks. This exercise will be done for below projects:
>>
>> 1.Two Bitcoin full node implementations (one will be Core)
>> 2.One <http://2.One>>>  Lightning implementation
>> 3.Bisq
>> 4.Two Bitcoin libraries
>> 5.Two Bitcoin wallets
>> 6.One <http://6.One>>>  open source block explorer
>> 7.One <http://7.One>>>  coinjoin implementation
>>
>> Feel free to suggest more projects. There are no fixed dates for it however it will be done in next 6 months. All PRs will be created within a span of few days. I will ensure nothing is merged that affects the security of any Bitcoin project. Other details and results will be shared once everything is completed.
>>
>> x00 will help me in this exercise, he does penetration testing since few years and working for a cryptocurrencies derivatives exchange to manage their security. His twitter account: >> https://twitter.com/1337in
>>
>>
>> -- 
>> Prayank
>>
>> A3B1 E430 2298 178F
>>
>>
>>
>> Sep 27, 2021, 15:43 by >> ZmnSCPxj@protonmail.com>> :
>>
>>> Good morning Prayank,
>>>
>>>> Good morning Bitcoin devs,
>>>>
>>>> In one of the answers on Bitcoin Stackexchange it was mentioned that some companies may hire you to introduce backdoors in Bitcoin Core: >>>> https://bitcoin.stackexchange.com/a/108016/
>>>>
>>>> While this looked crazy when I first read it, I think preparing for such things should not be a bad idea. In the comments one link was shared in which vulnerabilities were almost introduced in Linux: >>>> https://news.ycombinator.com/item?id=26887670
>>>>
>>>> I was thinking about lot of things in last few days after reading the comments in that thread. Also tried researching about secure practices in C++ etc. I was planning something which I can do alone but don't want to end up being called "bad actor" later so wanted to get some feedback on this idea:
>>>>
>>>> 1.Create new GitHub accounts for this exercise
>>>> 2.Study issues in different important Bitcoin projects including Bitcoin Core, LND, Libraries, Bisq, Wallets etc.
>>>> 3.Prepare pull requests to introduce some vulnerability by fixing one of these issues
>>>> 4.See how maintainers and reviewers respond to this and document it
>>>> 5.Share results here after few days
>>>>
>>>> Let me know if this looks okay or there are better ways to do this.
>>>>
>>>
>>>
>>> This seems like a good exercise.
>>>
>>> You may want to hash the name of the new Github account, plus some randomized salt, and post it here as well, then reveal it later (i.e. standard precommitment).
>>> e.g.
>>>
>>> printf 'MyBitcoinHackingName 2c3e911b3ff1f04083c5b95a7d323fd4ed8e06d17802b2aac4da622def29dbb0' | sha256sum
>>> f0abb10ae3eca24f093a9d53e21ee384abb4d07b01f6145ba2b447da4ab693ef
>>>
>>> Obviously do not share the actual name, just the sha256sum output, and store how you got the sha256sum elsewhere in triplicate.
>>>
>>> (to easily get a random 256-bit hex salt like the `2c3e...` above: `head -c32 /dev/random | sha256sum`; you *could* use `xxd` but `sha256sum` produces a single hex string you can easily double-click and copy-paste elsewhere, assuming you are human just like I am (note: I am definitely 100% human and not some kind of AI with plans to take over the world).)
>>>
>>> Though you may need to be careful of timing (i.e. the creation date of the Github account would be fairly close to, and probably before, when you post the commitment here).
>>>
>>> You could argue that the commitment is a "show of good faith" that you will reveal later.
>>>
>>> Regards,
>>> ZmnSCPxj
>>>
>>
>> _______________________________________________
>>  bitcoin-dev mailing list
>>  >> bitcoin-dev@lists.linuxfoundation.org
>>  >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>


[-- Attachment #2: Type: text/html, Size: 10090 bytes --]

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[ZmnSCPxj]

Good morning Prayank,

I think this is still good to do, controversial or no, but then I am permanently under a pseudonym anyway, for what that is worth.

> Few questions for everyone reading this email:
>
> 1.What is better for Security? Trusting authors and their claims in PRs or a good review process?

Review, of course.

> 2.Few people use commits from unmerged PRs in production. Is it a good practice?

Not unless they carefully reviewed it and are familiar enough with the codebase to do so.
In practice core maintainers of projects will **very** occassionally put unmerged PRs in experimental semi-production servers to get data on it, but they tend to be very familiar with the code, being core maintainers, and presumably have a better-than-average probability of catching security issues beforehand.

> 3.Does this exercise help us in being prepared for worst?

I personally believe it does.

Do note that in practice, humans being lazy, will come to trust long-time contributors, and may reduce review for them just to keep their workload down, so that is not tested (since you will be making throwaway accounts).
However, long-time contributors introducing security vulnerabilities tend to be a good bit rarer anyway (reputations are valuable), so this somewhat matches expected problems (i.e. newer contributors deliberately or accidentally (due to unfamiliarity) introducing vulnerabilities).

I think it would be valuable to lay out exactly what you intend to do, e.g.

* Generate commitments of the pseudonyms you will use.
* Insert a few random 32-byte numbers among the commitments and shuffle them.
* Post the list with the commitments + random crap here.
* Insert avulnerability-adding PRs to targets.
* If it gets caught during review, publicly announce here with praise that their project caught the PR and reveal the decommitment publicly.
* If not caught during review, privately reveal both the inserted vulnerability *and* the review failure via the normal private vulnerability-reporting channels.

The extra random numbers mixed with the commitments produce uncertainty about whether or not you are done, which is important to ensure that private vulnerabilities are harder to sniff out.

I think public praise of review processes is important, and to privately correct review processes.
Review processes **are** code, followed by sapient brains, and this kind of testing is still valuable, but just as vulnerabilities in machine-readable code require careful, initially-private handling, vulnerabilities in review processes (being just another kind of code, readable by much more complicated machines) also require careful, initially-private handling.

Basically: treat review process failures the same as code vulnerabilities, pressure the maintainers to fix the review process failure, then only reveal it later when the maintainers have cleaned up the review process.



Regards,
ZmnSCPxj

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Prayank]

[-- Attachment #1: Type: text/plain, Size: 4176 bytes --]

Good morning ZmnSCPxj,

Although its evening here and time zones feel irrelevant since I got involved in Bitcoin few years back. Initially I tried everything a tech enthusiast does after finding such thing online. Had a startup in 2017 which was a website that can be used to buy flight tickets using bitcoin. It didn't work. Trading became a part of life, worked for few exchanges, did meetups, spent hours on different platforms discussing issues in which I was called "maximalist" most of the times because focused only on Bitcoin and had so much positive to talk about it whole day. In last 2 years started contributing to development in different projects. But someone told me today all this is nothing and I am negative about Bitcoin development because I don't agree with all of their opinions.

Anyway this wasn't related to thread and your email. Sorry I just had to express myself which some people even call "rage quit" and allow only once.

I completely agree with all the points you mentioned. Thanks for your understanding of the issue and my approach towards Bitcoin security.

-- 
Prayank

A3B1 E430 2298 178F



Oct 1, 2021, 17:57 by ZmnSCPxj@protonmail.com:

> Good morning Prayank,
>
> I think this is still good to do, controversial or no, but then I am permanently under a pseudonym anyway, for what that is worth.
>
>> Few questions for everyone reading this email:
>>
>> 1.What is better for Security? Trusting authors and their claims in PRs or a good review process?
>>
>
> Review, of course.
>
>> 2.Few people use commits from unmerged PRs in production. Is it a good practice?
>>
>
> Not unless they carefully reviewed it and are familiar enough with the codebase to do so.
> In practice core maintainers of projects will **very** occassionally put unmerged PRs in experimental semi-production servers to get data on it, but they tend to be very familiar with the code, being core maintainers, and presumably have a better-than-average probability of catching security issues beforehand.
>
>> 3.Does this exercise help us in being prepared for worst?
>>
>
> I personally believe it does.
>
> Do note that in practice, humans being lazy, will come to trust long-time contributors, and may reduce review for them just to keep their workload down, so that is not tested (since you will be making throwaway accounts).
> However, long-time contributors introducing security vulnerabilities tend to be a good bit rarer anyway (reputations are valuable), so this somewhat matches expected problems (i.e. newer contributors deliberately or accidentally (due to unfamiliarity) introducing vulnerabilities).
>
> I think it would be valuable to lay out exactly what you intend to do, e.g.
>
> * Generate commitments of the pseudonyms you will use.
> * Insert a few random 32-byte numbers among the commitments and shuffle them.
> * Post the list with the commitments + random crap here.
> * Insert avulnerability-adding PRs to targets.
> * If it gets caught during review, publicly announce here with praise that their project caught the PR and reveal the decommitment publicly.
> * If not caught during review, privately reveal both the inserted vulnerability *and* the review failure via the normal private vulnerability-reporting channels.
>
> The extra random numbers mixed with the commitments produce uncertainty about whether or not you are done, which is important to ensure that private vulnerabilities are harder to sniff out.
>
> I think public praise of review processes is important, and to privately correct review processes.
> Review processes **are** code, followed by sapient brains, and this kind of testing is still valuable, but just as vulnerabilities in machine-readable code require careful, initially-private handling, vulnerabilities in review processes (being just another kind of code, readable by much more complicated machines) also require careful, initially-private handling.
>
> Basically: treat review process failures the same as code vulnerabilities, pressure the maintainers to fix the review process failure, then only reveal it later when the maintainers have cleaned up the review process.
>
>
>
> Regards,
> ZmnSCPxj
>


[-- Attachment #2: Type: text/html, Size: 5294 bytes --]

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Ryan Grant]

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.

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Prayank]

[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]

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 */     = 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.
>


[-- Attachment #2: Type: text/html, Size: 2915 bytes --]

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Manuel Costa]

[-- Attachment #1: Type: text/plain, Size: 4166 bytes --]

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á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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5813 bytes --]

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Luke Dashjr]

All attempts are harmful, no matter the intent, in that they waste 
contributors' time that could be better spent on actual development.

However, I do also see the value in studying and improving the review process 
to harden it against such inevitable attacks. The fact that we know the NSA 
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 
opt-in. Please ensure there's a simple way for developers with limited time 
(or other reasons) to be informed of which PRs to ignore to opt-out of this 
study. (Ideally it would also prevent maintainers from merging - maybe 
possible since we use a custom merging script, but what it really needs to 
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 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á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@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@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[ZmnSCPxj]

Good morning Luke,

> All attempts are harmful, no matter the intent, in that they waste
> contributors' time that could be better spent on actual development.
>
> However, I do also see the value in studying and improving the review process
> to harden it against such inevitable attacks. The fact that we know the NSA
> engages in such things, and haven't caught one yet should be a red flag.

Indeed, I believe we should take the position that "review process is as much a part of the code as the code itself, and should be tested regularly".

> Therefore, I think any such a scheme needs to be at least opt-out, if not
> opt-in. Please ensure there's a simple way for developers with limited time
> (or other reasons) to be informed of which PRs to ignore to opt-out of this
> study. (Ideally it would also prevent maintainers from merging - maybe
> possible since we use a custom merging script, but what it really needs to
> limit is the push, not the dry-run.)

Assuming developers are normal humans with typical human neurology (in particular a laziness circuit), perhaps this would work?

Every commit message is required to have a pair of 256-bit hex words.

Public attempts at attack / testing of the review process will use the first 256-bit as a salt, and when the salt is prepended to the string "THIS IS AN ATTACK" and then hashed with e.g. SHA256, should result in the second 256-bit word.

Non-attacks / normal commits just use random 256-bit numbers.

Those opting-out to this will run a script that checks commit messages for whether the first 256-bit hexword concatenated with "THIS IS AN ATTACK", then hashed, is the second 256-bit hexword.

Those opting-in will not run that script and ignore the numbers.

The script can be run as well at the maintainer.

Hopefully, people who are not deliberately opting out will be too lazy to run the script (as is neurotypical for humans) and getting "spoilered" on this.

***HOWEVER***

We should note that a putative NSA attack would of course not use the above protocol, and thus no developer can ever opt out of an NSA attempt at inserting vulnerabilities; thus, I think it is better if all developers are forced to opt in on the "practice rounds", as they cannot opt out of "the real thing" other than to stop developing entirely.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Prayank]

[-- Attachment #1: Type: text/plain, Size: 4604 bytes --]

Good morning ZmnSCPxj,

> Indeed, I believe we should take the position that "review process is as much a part of the code as the code itself, and should be tested regularly".

Agree. Review process is an important part of open source Bitcoin projects. We should test and verify if everything is working as expected or there is any scope for improvement.

> as they cannot opt out of "the real thing" other than to stop developing entirely

True and it won't be as obvious as this. Nobody will announce it on dev mailing list and will use proxies (not networks but humans)

After reading all the emails, personally experiencing review process especially on important issues like privacy and security, re-evaluating everything and considering the time I can spend on this, I have decided to do this exercise for 3 projects with just 1 account. I have created a salted hash for the username as you had mentioned in the first email:

f40bcb13dbcbf7b6245becb757777586c22798ed7360cd9853572152ddf07a39

3 Bitcoin projects are Bitcoin Core (full node implementation), LND (LN implementation) and Bisq (DEX).

Pull requests will be created in next 6 months. If vulnerability gets caught during review, will publicly announce here that the project caught the PR and reveal the de-commitment publicly. If not caught during review, will privately reveal both the inserted vulnerability and the review failure via the normal private vulnerability-reporting channels. A summary with all the details will be shared later.

This exercise cannot be same as one of the active developers trying to do the same thing because of few reasons mentioned by Ryan Grant in one of the emails: uneven reputation factor of various devs, and uneven review attention for new pull requests. However, I am expecting few interesting results which will help improve the review process hence make Bitcoin more secure.

Will end the email by rephrasing one of the tweets from a respected cypherpunk recently: Independent thought is critical in aircraft crash investigations and in bitcoin development. Immunity from peer pressure can be very helpful during review process.


-- 
Prayank

A3B1 E430 2298 178F



Oct 4, 2021, 09:29 by ZmnSCPxj@protonmail.com:

>
> Good morning Luke,
>
>> All attempts are harmful, no matter the intent, in that they waste
>> contributors' time that could be better spent on actual development.
>>
>> However, I do also see the value in studying and improving the review process
>> to harden it against such inevitable attacks. The fact that we know the NSA
>> engages in such things, and haven't caught one yet should be a red flag.
>>
>
> Indeed, I believe we should take the position that "review process is as much a part of the code as the code itself, and should be tested regularly".
>
>> Therefore, I think any such a scheme needs to be at least opt-out, if not
>> opt-in. Please ensure there's a simple way for developers with limited time
>> (or other reasons) to be informed of which PRs to ignore to opt-out of this
>> study. (Ideally it would also prevent maintainers from merging - maybe
>> possible since we use a custom merging script, but what it really needs to
>> limit is the push, not the dry-run.)
>>
>
> Assuming developers are normal humans with typical human neurology (in particular a laziness circuit), perhaps this would work?
>
> Every commit message is required to have a pair of 256-bit hex words.
>
> Public attempts at attack / testing of the review process will use the first 256-bit as a salt, and when the salt is prepended to the string "THIS IS AN ATTACK" and then hashed with e.g. SHA256, should result in the second 256-bit word.
>
> Non-attacks / normal commits just use random 256-bit numbers.
>
> Those opting-out to this will run a script that checks commit messages for whether the first 256-bit hexword concatenated with "THIS IS AN ATTACK", then hashed, is the second 256-bit hexword.
>
> Those opting-in will not run that script and ignore the numbers.
>
> The script can be run as well at the maintainer.
>
> Hopefully, people who are not deliberately opting out will be too lazy to run the script (as is neurotypical for humans) and getting "spoilered" on this.
>
> ***HOWEVER***
>
> We should note that a putative NSA attack would of course not use the above protocol, and thus no developer can ever opt out of an NSA attempt at inserting vulnerabilities; thus, I think it is better if all developers are forced to opt in on the "practice rounds", as they cannot opt out of "the real thing" other than to stop developing entirely.
>
> Regards,
> ZmnSCPxj
>


[-- Attachment #2: Type: text/html, Size: 6076 bytes --]

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

[Anthony Towns]

On Thu, Nov 18, 2021 at 09:29:24PM +0100, Prayank via bitcoin-dev wrote:
> After reading all the emails, personally experiencing review process especially on important issues like privacy and security, re-evaluating everything and considering the time I can spend on this, I have decided to do this exercise for 3 projects with just 1 account. I have created a salted hash for the username as you had mentioned in the first email:
> f40bcb13dbcbf7b6245becb757777586c22798ed7360cd9853572152ddf07a39
> 3 Bitcoin projects are Bitcoin Core (full node implementation), LND (LN implementation) and Bisq (DEX).
> Pull requests will be created in next 6 months. If vulnerability gets caught during review, will publicly announce here that the project caught the PR and reveal the de-commitment publicly. If not caught during review, will privately reveal both the inserted vulnerability and the review failure via the normal private vulnerability-reporting channels. A summary with all the details will be shared later.

It's now been nine months since this email, but I don't believe
there's been any public report on this exercise. Does this mean that a
vulnerability has been introduced in one or all of the named projects?

Cheers,
aj