* [Bitcoin-development] bitcoin pull requests @ 2013-04-01 8:26 Melvin Carvalho 2013-04-01 18:28 ` Petr Praus 0 siblings, 1 reply; 15+ messages in thread From: Melvin Carvalho @ 2013-04-01 8:26 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 356 bytes --] I was just looking at: https://bitcointalk.org/index.php?topic=4571.0 I'm just curious if there is a possible attack vector here based on the fact that git uses the relatively week SHA1 Could a seemingly innocuous pull request generate another file with a backdoor/nonce combination that slips under the radar? Apologies if this has come up before ... [-- Attachment #2: Type: text/html, Size: 506 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] bitcoin pull requests 2013-04-01 8:26 [Bitcoin-development] bitcoin pull requests Melvin Carvalho @ 2013-04-01 18:28 ` Petr Praus 2013-04-01 21:52 ` Melvin Carvalho 0 siblings, 1 reply; 15+ messages in thread From: Petr Praus @ 2013-04-01 18:28 UTC (permalink / raw) To: Melvin Carvalho; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1640 bytes --] An attacker would have to find a collision between two specific pieces of code - his malicious code and a useful innoculous code that would be accepted as pull request. This is the second, much harder case in the birthday problem. When people talk about SHA-1 being broken they actually mean the first case in the birthday problem - find any two arbitrary values that hash to the same value. So, no I don't think it's a feasible attack vector any time soon. Besides, with that kind of hashing power, it might be more feasible to cause problems in the chain by e.g. constantly splitting it. On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho@gmail•com> wrote: > I was just looking at: > > https://bitcointalk.org/index.php?topic=4571.0 > > I'm just curious if there is a possible attack vector here based on the > fact that git uses the relatively week SHA1 > > Could a seemingly innocuous pull request generate another file with a > backdoor/nonce combination that slips under the radar? > > Apologies if this has come up before ... > > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 2411 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] bitcoin pull requests 2013-04-01 18:28 ` Petr Praus @ 2013-04-01 21:52 ` Melvin Carvalho 2013-04-01 22:10 ` Will 0 siblings, 1 reply; 15+ messages in thread From: Melvin Carvalho @ 2013-04-01 21:52 UTC (permalink / raw) To: Petr Praus; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1914 bytes --] On 1 April 2013 20:28, Petr Praus <petr@praus•net> wrote: > An attacker would have to find a collision between two specific pieces of > code - his malicious code and a useful innoculous code that would be > accepted as pull request. This is the second, much harder case in the > birthday problem. When people talk about SHA-1 being broken they actually > mean the first case in the birthday problem - find any two arbitrary values > that hash to the same value. So, no I don't think it's a feasible attack > vector any time soon. > > Besides, with that kind of hashing power, it might be more feasible to > cause problems in the chain by e.g. constantly splitting it. > OK, maybe im being *way* too paranoid here ... but what if someone had access to github, could they replace one file with one they had prepared at some point? > > > On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho@gmail•com> wrote: > >> I was just looking at: >> >> https://bitcointalk.org/index.php?topic=4571.0 >> >> I'm just curious if there is a possible attack vector here based on the >> fact that git uses the relatively week SHA1 >> >> Could a seemingly innocuous pull request generate another file with a >> backdoor/nonce combination that slips under the radar? >> >> Apologies if this has come up before ... >> >> >> ------------------------------------------------------------------------------ >> Own the Future-Intel® Level Up Game Demo Contest 2013 >> Rise to greatness in Intel's independent game demo contest. >> Compete for recognition, cash, and the chance to get your game >> on Steam. $5K grand prize plus 10 genre and skill prizes. >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > [-- Attachment #2: Type: text/html, Size: 3164 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] bitcoin pull requests 2013-04-01 21:52 ` Melvin Carvalho @ 2013-04-01 22:10 ` Will 2013-04-01 22:27 ` Melvin Carvalho 0 siblings, 1 reply; 15+ messages in thread From: Will @ 2013-04-01 22:10 UTC (permalink / raw) To: Melvin Carvalho; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3271 bytes --] The threat of a SHA1 collision attack to insert a malicious pull request are tiny compared with the other threats - e.g. github being compromised, one of the core developers' passwords being compromised, one of the core developers going rogue, sourceforge (distribution site) being compromised etc etc... believe me there's a lot more to worry about than a SHA1 attack... Not meaning to scare, just to put things in perspective - this is why we all need to peer review each others commits and keep an eye out for suspicious commits, leverage the benefits of this project being open source and easily peer reviewed. Will On 1 April 2013 23:52, Melvin Carvalho <melvincarvalho@gmail•com> wrote: > > > > On 1 April 2013 20:28, Petr Praus <petr@praus•net> wrote: > >> An attacker would have to find a collision between two specific pieces of >> code - his malicious code and a useful innoculous code that would be >> accepted as pull request. This is the second, much harder case in the >> birthday problem. When people talk about SHA-1 being broken they actually >> mean the first case in the birthday problem - find any two arbitrary values >> that hash to the same value. So, no I don't think it's a feasible attack >> vector any time soon. >> >> Besides, with that kind of hashing power, it might be more feasible to >> cause problems in the chain by e.g. constantly splitting it. >> > > OK, maybe im being *way* too paranoid here ... but what if someone had > access to github, could they replace one file with one they had prepared at > some point? > > >> >> >> On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho@gmail•com> wrote: >> >>> I was just looking at: >>> >>> https://bitcointalk.org/index.php?topic=4571.0 >>> >>> I'm just curious if there is a possible attack vector here based on the >>> fact that git uses the relatively week SHA1 >>> >>> Could a seemingly innocuous pull request generate another file with a >>> backdoor/nonce combination that slips under the radar? >>> >>> Apologies if this has come up before ... >>> >>> >>> ------------------------------------------------------------------------------ >>> Own the Future-Intel® Level Up Game Demo Contest 2013 >>> Rise to greatness in Intel's independent game demo contest. >>> Compete for recognition, cash, and the chance to get your game >>> on Steam. $5K grand prize plus 10 genre and skill prizes. >>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists•sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>> >>> >> > > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 5146 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] bitcoin pull requests 2013-04-01 22:10 ` Will @ 2013-04-01 22:27 ` Melvin Carvalho 2013-04-01 22:51 ` Roy Badami 0 siblings, 1 reply; 15+ messages in thread From: Melvin Carvalho @ 2013-04-01 22:27 UTC (permalink / raw) To: Will; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3855 bytes --] On 2 April 2013 00:10, Will <will@phase•net> wrote: > The threat of a SHA1 collision attack to insert a malicious pull request > are tiny compared with the other threats - e.g. github being compromised, > one of the core developers' passwords being compromised, one of the core > developers going rogue, sourceforge (distribution site) being compromised > etc etc... believe me there's a lot more to worry about than a SHA1 > attack... > > Not meaning to scare, just to put things in perspective - this is why we > all need to peer review each others commits and keep an eye out for > suspicious commits, leverage the benefits of this project being open source > and easily peer reviewed. > Very good points, and I think you're absolutely right. But just running the numbers, to get the picture, based of scheiner's statistics: http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html We're talking about a million terrahashes = 2^60 right? With the block chain, you only have a 10 minute window, but with source code you have a longer time to prepare. Couldnt this be done with an ASIC in about a week? > > Will > > > On 1 April 2013 23:52, Melvin Carvalho <melvincarvalho@gmail•com> wrote: > >> >> >> >> On 1 April 2013 20:28, Petr Praus <petr@praus•net> wrote: >> >>> An attacker would have to find a collision between two specific pieces >>> of code - his malicious code and a useful innoculous code that would be >>> accepted as pull request. This is the second, much harder case in the >>> birthday problem. When people talk about SHA-1 being broken they actually >>> mean the first case in the birthday problem - find any two arbitrary values >>> that hash to the same value. So, no I don't think it's a feasible attack >>> vector any time soon. >>> >>> Besides, with that kind of hashing power, it might be more feasible to >>> cause problems in the chain by e.g. constantly splitting it. >>> >> >> OK, maybe im being *way* too paranoid here ... but what if someone had >> access to github, could they replace one file with one they had prepared at >> some point? >> >> >>> >>> >>> On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho@gmail•com> wrote: >>> >>>> I was just looking at: >>>> >>>> https://bitcointalk.org/index.php?topic=4571.0 >>>> >>>> I'm just curious if there is a possible attack vector here based on the >>>> fact that git uses the relatively week SHA1 >>>> >>>> Could a seemingly innocuous pull request generate another file with a >>>> backdoor/nonce combination that slips under the radar? >>>> >>>> Apologies if this has come up before ... >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Own the Future-Intel® Level Up Game Demo Contest 2013 >>>> Rise to greatness in Intel's independent game demo contest. >>>> Compete for recognition, cash, and the chance to get your game >>>> on Steam. $5K grand prize plus 10 genre and skill prizes. >>>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d >>>> _______________________________________________ >>>> Bitcoin-development mailing list >>>> Bitcoin-development@lists•sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>>> >>>> >>> >> >> >> ------------------------------------------------------------------------------ >> Own the Future-Intel® Level Up Game Demo Contest 2013 >> Rise to greatness in Intel's independent game demo contest. >> Compete for recognition, cash, and the chance to get your game >> on Steam. $5K grand prize plus 10 genre and skill prizes. >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > [-- Attachment #2: Type: text/html, Size: 6500 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] bitcoin pull requests 2013-04-01 22:27 ` Melvin Carvalho @ 2013-04-01 22:51 ` Roy Badami 2013-04-01 22:54 ` Roy Badami 0 siblings, 1 reply; 15+ messages in thread From: Roy Badami @ 2013-04-01 22:51 UTC (permalink / raw) To: Melvin Carvalho; +Cc: Bitcoin Dev The attack Schneier is talking about is a collision attack (i.e. it creates two messages with the same hash, but you don't get to choose either of the messages). It's not a second preimage attack, which is what you would need to be able to create a message that hashes to the same value of an existing message. (And it neither have anything to do with the birthday paradox, BTW - which relates to the chance of eventually finding two messages that hash to the same value by pure change) If someone gets malicious code into the repo, it's going to be by social engineering, not by breaking the cyrpto. roy On Tue, Apr 02, 2013 at 12:27:51AM +0200, Melvin Carvalho wrote: > On 2 April 2013 00:10, Will <will@phase•net> wrote: > > > The threat of a SHA1 collision attack to insert a malicious pull request > > are tiny compared with the other threats - e.g. github being compromised, > > one of the core developers' passwords being compromised, one of the core > > developers going rogue, sourceforge (distribution site) being compromised > > etc etc... believe me there's a lot more to worry about than a SHA1 > > attack... > > > > Not meaning to scare, just to put things in perspective - this is why we > > all need to peer review each others commits and keep an eye out for > > suspicious commits, leverage the benefits of this project being open source > > and easily peer reviewed. > > > > Very good points, and I think you're absolutely right. > > But just running the numbers, to get the picture, based of scheiner's > statistics: > > http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html > > We're talking about a million terrahashes = 2^60 right? > > With the block chain, you only have a 10 minute window, but with source > code you have a longer time to prepare. > > Couldnt this be done with an ASIC in about a week? > > > > > > > Will > > > > > > On 1 April 2013 23:52, Melvin Carvalho <melvincarvalho@gmail•com> wrote: > > > >> > >> > >> > >> On 1 April 2013 20:28, Petr Praus <petr@praus•net> wrote: > >> > >>> An attacker would have to find a collision between two specific pieces > >>> of code - his malicious code and a useful innoculous code that would be > >>> accepted as pull request. This is the second, much harder case in the > >>> birthday problem. When people talk about SHA-1 being broken they actually > >>> mean the first case in the birthday problem - find any two arbitrary values > >>> that hash to the same value. So, no I don't think it's a feasible attack > >>> vector any time soon. > >>> > >>> Besides, with that kind of hashing power, it might be more feasible to > >>> cause problems in the chain by e.g. constantly splitting it. > >>> > >> > >> OK, maybe im being *way* too paranoid here ... but what if someone had > >> access to github, could they replace one file with one they had prepared at > >> some point? > >> > >> > >>> > >>> > >>> On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho@gmail•com> wrote: > >>> > >>>> I was just looking at: > >>>> > >>>> https://bitcointalk.org/index.php?topic=4571.0 > >>>> > >>>> I'm just curious if there is a possible attack vector here based on the > >>>> fact that git uses the relatively week SHA1 > >>>> > >>>> Could a seemingly innocuous pull request generate another file with a > >>>> backdoor/nonce combination that slips under the radar? > >>>> > >>>> Apologies if this has come up before ... > >>>> > >>>> > >>>> ------------------------------------------------------------------------------ > >>>> Own the Future-Intel® Level Up Game Demo Contest 2013 > >>>> Rise to greatness in Intel's independent game demo contest. > >>>> Compete for recognition, cash, and the chance to get your game > >>>> on Steam. $5K grand prize plus 10 genre and skill prizes. > >>>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > >>>> _______________________________________________ > >>>> Bitcoin-development mailing list > >>>> Bitcoin-development@lists•sourceforge.net > >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >>>> > >>>> > >>> > >> > >> > >> ------------------------------------------------------------------------------ > >> Own the Future-Intel® Level Up Game Demo Contest 2013 > >> Rise to greatness in Intel's independent game demo contest. > >> Compete for recognition, cash, and the chance to get your game > >> on Steam. $5K grand prize plus 10 genre and skill prizes. > >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > >> _______________________________________________ > >> Bitcoin-development mailing list > >> Bitcoin-development@lists•sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >> > >> > > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] bitcoin pull requests 2013-04-01 22:51 ` Roy Badami @ 2013-04-01 22:54 ` Roy Badami 2013-04-03 3:41 ` Wladimir 0 siblings, 1 reply; 15+ messages in thread From: Roy Badami @ 2013-04-01 22:54 UTC (permalink / raw) To: Melvin Carvalho; +Cc: Bitcoin Dev And the moment I hit send I realised it's not necessarily true. Conceivably, a collision attack might help you craft two commits (one good, one bad) with the same hash. But I still maintain what I just posted is true: if someone gets malicious code into the repo, it's going to be by social engineering, not by breaking the cyrpto. roy On Mon, Apr 01, 2013 at 11:51:07PM +0100, Roy Badami wrote: > The attack Schneier is talking about is a collision attack (i.e. it > creates two messages with the same hash, but you don't get to choose > either of the messages). It's not a second preimage attack, which is > what you would need to be able to create a message that hashes to the > same value of an existing message. > > (And it neither have anything to do with the birthday paradox, BTW - > which relates to the chance of eventually finding two messages that > hash to the same value by pure change) > > If someone gets malicious code into the repo, it's going to be by > social engineering, not by breaking the cyrpto. > > roy > > On Tue, Apr 02, 2013 at 12:27:51AM +0200, Melvin Carvalho wrote: > > On 2 April 2013 00:10, Will <will@phase•net> wrote: > > > > > The threat of a SHA1 collision attack to insert a malicious pull request > > > are tiny compared with the other threats - e.g. github being compromised, > > > one of the core developers' passwords being compromised, one of the core > > > developers going rogue, sourceforge (distribution site) being compromised > > > etc etc... believe me there's a lot more to worry about than a SHA1 > > > attack... > > > > > > Not meaning to scare, just to put things in perspective - this is why we > > > all need to peer review each others commits and keep an eye out for > > > suspicious commits, leverage the benefits of this project being open source > > > and easily peer reviewed. > > > > > > > Very good points, and I think you're absolutely right. > > > > But just running the numbers, to get the picture, based of scheiner's > > statistics: > > > > http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html > > > > We're talking about a million terrahashes = 2^60 right? > > > > With the block chain, you only have a 10 minute window, but with source > > code you have a longer time to prepare. > > > > Couldnt this be done with an ASIC in about a week? > > > > > > > > > > > > Will > > > > > > > > > On 1 April 2013 23:52, Melvin Carvalho <melvincarvalho@gmail•com> wrote: > > > > > >> > > >> > > >> > > >> On 1 April 2013 20:28, Petr Praus <petr@praus•net> wrote: > > >> > > >>> An attacker would have to find a collision between two specific pieces > > >>> of code - his malicious code and a useful innoculous code that would be > > >>> accepted as pull request. This is the second, much harder case in the > > >>> birthday problem. When people talk about SHA-1 being broken they actually > > >>> mean the first case in the birthday problem - find any two arbitrary values > > >>> that hash to the same value. So, no I don't think it's a feasible attack > > >>> vector any time soon. > > >>> > > >>> Besides, with that kind of hashing power, it might be more feasible to > > >>> cause problems in the chain by e.g. constantly splitting it. > > >>> > > >> > > >> OK, maybe im being *way* too paranoid here ... but what if someone had > > >> access to github, could they replace one file with one they had prepared at > > >> some point? > > >> > > >> > > >>> > > >>> > > >>> On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho@gmail•com> wrote: > > >>> > > >>>> I was just looking at: > > >>>> > > >>>> https://bitcointalk.org/index.php?topic=4571.0 > > >>>> > > >>>> I'm just curious if there is a possible attack vector here based on the > > >>>> fact that git uses the relatively week SHA1 > > >>>> > > >>>> Could a seemingly innocuous pull request generate another file with a > > >>>> backdoor/nonce combination that slips under the radar? > > >>>> > > >>>> Apologies if this has come up before ... > > >>>> > > >>>> > > >>>> ------------------------------------------------------------------------------ > > >>>> Own the Future-Intel® Level Up Game Demo Contest 2013 > > >>>> Rise to greatness in Intel's independent game demo contest. > > >>>> Compete for recognition, cash, and the chance to get your game > > >>>> on Steam. $5K grand prize plus 10 genre and skill prizes. > > >>>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > > >>>> _______________________________________________ > > >>>> Bitcoin-development mailing list > > >>>> Bitcoin-development@lists•sourceforge.net > > >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > >>>> > > >>>> > > >>> > > >> > > >> > > >> ------------------------------------------------------------------------------ > > >> Own the Future-Intel® Level Up Game Demo Contest 2013 > > >> Rise to greatness in Intel's independent game demo contest. > > >> Compete for recognition, cash, and the chance to get your game > > >> on Steam. $5K grand prize plus 10 genre and skill prizes. > > >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > > >> _______________________________________________ > > >> Bitcoin-development mailing list > > >> Bitcoin-development@lists•sourceforge.net > > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > >> > > >> > > > > > > ------------------------------------------------------------------------------ > > Own the Future-Intel® Level Up Game Demo Contest 2013 > > Rise to greatness in Intel's independent game demo contest. > > Compete for recognition, cash, and the chance to get your game > > on Steam. $5K grand prize plus 10 genre and skill prizes. > > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] bitcoin pull requests 2013-04-01 22:54 ` Roy Badami @ 2013-04-03 3:41 ` Wladimir 2013-04-03 3:51 ` Jeff Garzik 0 siblings, 1 reply; 15+ messages in thread From: Wladimir @ 2013-04-03 3:41 UTC (permalink / raw) To: Roy Badami; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 7858 bytes --] Maybe now that bitcoin is growing out of the toy phase it's an idea to start gpg signing commits, like the Linux kernel ( https://lwn.net/Articles/466468/). But I suppose then we can't use github anymore to merge as-is and need manual steps? Wladimir On Tue, Apr 2, 2013 at 12:54 AM, Roy Badami <roy@gnomon•org.uk> wrote: > And the moment I hit send I realised it's not necessarily true. > Conceivably, a collision attack might help you craft two commits (one > good, one bad) with the same hash. > > But I still maintain what I just posted is true: if someone gets > malicious code into the repo, it's going to be by social engineering, > not by breaking the cyrpto. > > roy > > > On Mon, Apr 01, 2013 at 11:51:07PM +0100, Roy Badami wrote: > > The attack Schneier is talking about is a collision attack (i.e. it > > creates two messages with the same hash, but you don't get to choose > > either of the messages). It's not a second preimage attack, which is > > what you would need to be able to create a message that hashes to the > > same value of an existing message. > > > > (And it neither have anything to do with the birthday paradox, BTW - > > which relates to the chance of eventually finding two messages that > > hash to the same value by pure change) > > > > If someone gets malicious code into the repo, it's going to be by > > social engineering, not by breaking the cyrpto. > > > > roy > > > > On Tue, Apr 02, 2013 at 12:27:51AM +0200, Melvin Carvalho wrote: > > > On 2 April 2013 00:10, Will <will@phase•net> wrote: > > > > > > > The threat of a SHA1 collision attack to insert a malicious pull > request > > > > are tiny compared with the other threats - e.g. github being > compromised, > > > > one of the core developers' passwords being compromised, one of the > core > > > > developers going rogue, sourceforge (distribution site) being > compromised > > > > etc etc... believe me there's a lot more to worry about than a SHA1 > > > > attack... > > > > > > > > Not meaning to scare, just to put things in perspective - this is > why we > > > > all need to peer review each others commits and keep an eye out for > > > > suspicious commits, leverage the benefits of this project being open > source > > > > and easily peer reviewed. > > > > > > > > > > Very good points, and I think you're absolutely right. > > > > > > But just running the numbers, to get the picture, based of scheiner's > > > statistics: > > > > > > http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html > > > > > > We're talking about a million terrahashes = 2^60 right? > > > > > > With the block chain, you only have a 10 minute window, but with source > > > code you have a longer time to prepare. > > > > > > Couldnt this be done with an ASIC in about a week? > > > > > > > > > > > > > > > > > Will > > > > > > > > > > > > On 1 April 2013 23:52, Melvin Carvalho <melvincarvalho@gmail•com> > wrote: > > > > > > > >> > > > >> > > > >> > > > >> On 1 April 2013 20:28, Petr Praus <petr@praus•net> wrote: > > > >> > > > >>> An attacker would have to find a collision between two specific > pieces > > > >>> of code - his malicious code and a useful innoculous code that > would be > > > >>> accepted as pull request. This is the second, much harder case in > the > > > >>> birthday problem. When people talk about SHA-1 being broken they > actually > > > >>> mean the first case in the birthday problem - find any two > arbitrary values > > > >>> that hash to the same value. So, no I don't think it's a feasible > attack > > > >>> vector any time soon. > > > >>> > > > >>> Besides, with that kind of hashing power, it might be more > feasible to > > > >>> cause problems in the chain by e.g. constantly splitting it. > > > >>> > > > >> > > > >> OK, maybe im being *way* too paranoid here ... but what if someone > had > > > >> access to github, could they replace one file with one they had > prepared at > > > >> some point? > > > >> > > > >> > > > >>> > > > >>> > > > >>> On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho@gmail•com> > wrote: > > > >>> > > > >>>> I was just looking at: > > > >>>> > > > >>>> https://bitcointalk.org/index.php?topic=4571.0 > > > >>>> > > > >>>> I'm just curious if there is a possible attack vector here based > on the > > > >>>> fact that git uses the relatively week SHA1 > > > >>>> > > > >>>> Could a seemingly innocuous pull request generate another file > with a > > > >>>> backdoor/nonce combination that slips under the radar? > > > >>>> > > > >>>> Apologies if this has come up before ... > > > >>>> > > > >>>> > > > >>>> > ------------------------------------------------------------------------------ > > > >>>> Own the Future-Intel® Level Up Game Demo Contest 2013 > > > >>>> Rise to greatness in Intel's independent game demo contest. > > > >>>> Compete for recognition, cash, and the chance to get your game > > > >>>> on Steam. $5K grand prize plus 10 genre and skill prizes. > > > >>>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > > > >>>> _______________________________________________ > > > >>>> Bitcoin-development mailing list > > > >>>> Bitcoin-development@lists•sourceforge.net > > > >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > >>>> > > > >>>> > > > >>> > > > >> > > > >> > > > >> > ------------------------------------------------------------------------------ > > > >> Own the Future-Intel® Level Up Game Demo Contest 2013 > > > >> Rise to greatness in Intel's independent game demo contest. > > > >> Compete for recognition, cash, and the chance to get your game > > > >> on Steam. $5K grand prize plus 10 genre and skill prizes. > > > >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > > > >> _______________________________________________ > > > >> Bitcoin-development mailing list > > > >> Bitcoin-development@lists•sourceforge.net > > > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > >> > > > >> > > > > > > > > > > ------------------------------------------------------------------------------ > > > Own the Future-Intel® Level Up Game Demo Contest 2013 > > > Rise to greatness in Intel's independent game demo contest. > > > Compete for recognition, cash, and the chance to get your game > > > on Steam. $5K grand prize plus 10 genre and skill prizes. > > > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > > > > > _______________________________________________ > > > Bitcoin-development mailing list > > > Bitcoin-development@lists•sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > ------------------------------------------------------------------------------ > > Own the Future-Intel® Level Up Game Demo Contest 2013 > > Rise to greatness in Intel's independent game demo contest. > > Compete for recognition, cash, and the chance to get your game > > on Steam. $5K grand prize plus 10 genre and skill prizes. > > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 11849 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] bitcoin pull requests 2013-04-03 3:41 ` Wladimir @ 2013-04-03 3:51 ` Jeff Garzik 2013-04-03 15:52 ` grarpamp 0 siblings, 1 reply; 15+ messages in thread From: Jeff Garzik @ 2013-04-03 3:51 UTC (permalink / raw) To: Wladimir; +Cc: Bitcoin Dev On Tue, Apr 2, 2013 at 11:41 PM, Wladimir <laanwj@gmail•com> wrote: > Maybe now that bitcoin is growing out of the toy phase it's an idea to start > gpg signing commits, like the Linux kernel > (https://lwn.net/Articles/466468/). > > But I suppose then we can't use github anymore to merge as-is and need > manual steps? Correct, that rules out github, AFAICS. Though, honestly, when I ACK that means I read the code, which is more important than the author really. github seems fine for that still, though I do wonder if there is a race possible, * sneak uploads innocent branch sneak/bitcoin.git #innocent * sneak creates pull req * just before I click "pull", sneak rebases the branch to something evil -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti•com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] bitcoin pull requests 2013-04-03 3:51 ` Jeff Garzik @ 2013-04-03 15:52 ` grarpamp 2013-04-03 16:05 ` Gavin Andresen 0 siblings, 1 reply; 15+ messages in thread From: grarpamp @ 2013-04-03 15:52 UTC (permalink / raw) To: bitcoin-development >> gpg signing commits, like the Linux kernel > Though, honestly, when I ACK that means I read the code, which is more > important than the author really. github seems fine for that still, > though I do wonder if there is a race possible, > > * just before I click "pull", sneak rebases the branch to something evil You might want to look at http://www.monotone.ca/, it does a good job of integrating crypto and review primitives into the workflow. It also has some reliable network distribution models (netsync) that work well over things like Tor, in case a new developer (or old Satoshi) doesn't wish to be in the public light. http://www.monotone.ca/monotone.html Once you have the crypto, it always boils down to human risk factors, rogue, password, cracks, etc which are harder. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] bitcoin pull requests 2013-04-03 15:52 ` grarpamp @ 2013-04-03 16:05 ` Gavin Andresen 2013-04-03 16:23 ` grarpamp 0 siblings, 1 reply; 15+ messages in thread From: Gavin Andresen @ 2013-04-03 16:05 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 394 bytes --] I would rather we spend time working to make users' bitcoins safe EVEN IF their bitcoin software is compromised. Eliminate the "if you get a bad bitcoin-qt.exe somehow you're in big trouble" risk entirely, instead of worrying about unlikely scenarios like a timing attack in between ACKs/pulls. Eliminate one piece of software as the possible single point of failure... -- -- Gavin Andresen [-- Attachment #2: Type: text/html, Size: 475 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] bitcoin pull requests 2013-04-03 16:05 ` Gavin Andresen @ 2013-04-03 16:23 ` grarpamp [not found] ` <CAAS2fgT06RHBO_0stKQAYLPB39ZAzaCVduFZJROjSzXUP4Db+g@mail.gmail.com> 0 siblings, 1 reply; 15+ messages in thread From: grarpamp @ 2013-04-03 16:23 UTC (permalink / raw) To: bitcoin-development > Eliminate the "if you get a bad bitcoin-qt.exe somehow you're in big > trouble" risk entirely This isn't really possible. A trojaned client will spend your coin as easily as the owner can, passphrases will be logged, windows box will be owned, secondary remote spendauth sigs into the network chain break similarly, securely hashcheck the trojaned client from cracked userspace on a hacked dll/kernel with uefi backdoor and a trojaned hasher, etc. It's easier for a few developers to meet in person to init and sig a new repo than to try fixing the world's userland and users :) At least that way you get something verifiable back to the root. ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <CAAS2fgT06RHBO_0stKQAYLPB39ZAzaCVduFZJROjSzXUP4Db+g@mail.gmail.com>]
* Re: [Bitcoin-development] bitcoin pull requests [not found] ` <CAAS2fgT06RHBO_0stKQAYLPB39ZAzaCVduFZJROjSzXUP4Db+g@mail.gmail.com> @ 2013-04-03 18:12 ` grarpamp 2013-04-04 9:11 ` Mike Hearn 0 siblings, 1 reply; 15+ messages in thread From: grarpamp @ 2013-04-03 18:12 UTC (permalink / raw) To: bitcoin-development > Users will have available multisig addresses which require > transactions to be signed off by a wallet HSM. (E.g. a keyfob Hardware is a good thing. But only if you do the crypto in the hardware and trust the hardware and its attack models ;) For instance, the fingerprint readers you see everywhere... many of them just present the raw fingerprint scan to the host (and host software), instead of hashing the fingerprint internally and using that as primitive in crypto exchanges with the host. They cheaped out and/or didn't think. So oops, there went both your security (host replay) and your personal privacy (biometrics), outside of your control. All with no protection against physical fingerprint lifting. > This doesn't remove the need to improve repository integrity. ... but > repository integrity is a general problem that is applicable to many > things (after all, what does it matter if you can't compromise Bitcoin > if you can compromise boost, openssl, or gcc?) Yes, that case would matter zero to the end product. However having a strong repo permits better auditing of the BTC codebase. That's a good thing, and eliminates the need to talk chicken and egg. > It's probably best > that Bitcoin specalists stay focused on Bitcoin security measures, and > other people interested in repository security come and help out > improving it. An obvious area of improvement might be oddity > detection and alerting: It's weird that I can rewrite history on > github, so long as I do it quickly, without anyone noticing. If no one is verifying the repo, sure, even entire repos could be swapped out for seemingly identical ones. Many repos do not have any strong internal verification structures at all, and they run on filesystems that accept bitrot. Take a look at some OS's... OpenBSD and FreeBSD, supposedly the more secure ones out there... both use legacy repos on FFS. Seems rather ironic in the lol department. Thankfully some people out there are finally getting a clue on these issues, making and learning the tools, converting and migrating things, working on top down signed build and distribution chain, etc... so maybe in ten years the opensource world will be much farther ahead. Or at least have a strong audit trail. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] bitcoin pull requests 2013-04-03 18:12 ` grarpamp @ 2013-04-04 9:11 ` Mike Hearn 2013-04-04 10:04 ` Mike Hearn 0 siblings, 1 reply; 15+ messages in thread From: Mike Hearn @ 2013-04-04 9:11 UTC (permalink / raw) To: grarpamp; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3246 bytes --] My general hope/vague plan for bitcoinj based wallets is to get them all on to automatic updates with threshold signatures. Combined with regular audits of the initial downloads for new users, that should give a pretty safe result that is immune to a developer going rogue. On Wed, Apr 3, 2013 at 7:12 PM, grarpamp <grarpamp@gmail•com> wrote: > > Users will have available multisig addresses which require > > transactions to be signed off by a wallet HSM. (E.g. a keyfob > > Hardware is a good thing. But only if you do the crypto in the > hardware and trust the hardware and its attack models ;) For > instance, the fingerprint readers you see everywhere... many > of them just present the raw fingerprint scan to the host (and > host software), instead of hashing the fingerprint internally and > using that as primitive in crypto exchanges with the host. They > cheaped out and/or didn't think. So oops, there went both your > security (host replay) and your personal privacy (biometrics), > outside of your control. All with no protection against physical > fingerprint lifting. > > > This doesn't remove the need to improve repository integrity. ... but > > repository integrity is a general problem that is applicable to many > > things (after all, what does it matter if you can't compromise Bitcoin > > if you can compromise boost, openssl, or gcc?) > > Yes, that case would matter zero to the end product. However > having a strong repo permits better auditing of the BTC codebase. > That's a good thing, and eliminates the need to talk chicken and > egg. > > > It's probably best > > that Bitcoin specalists stay focused on Bitcoin security measures, and > > other people interested in repository security come and help out > > improving it. An obvious area of improvement might be oddity > > detection and alerting: It's weird that I can rewrite history on > > github, so long as I do it quickly, without anyone noticing. > > If no one is verifying the repo, sure, even entire repos could be > swapped out for seemingly identical ones. > > Many repos do not have any strong internal verification structures > at all, and they run on filesystems that accept bitrot. > Take a look at some OS's... OpenBSD and FreeBSD, supposedly > the more secure ones out there... both use legacy repos on FFS. > Seems rather ironic in the lol department. > > Thankfully some people out there are finally getting a clue on these > issues, making and learning the tools, converting and migrating > things, working on top down signed build and distribution chain, etc... > so maybe in ten years the opensource world will be much farther > ahead. Or at least have a strong audit trail. > > > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 4084 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] bitcoin pull requests 2013-04-04 9:11 ` Mike Hearn @ 2013-04-04 10:04 ` Mike Hearn 0 siblings, 0 replies; 15+ messages in thread From: Mike Hearn @ 2013-04-04 10:04 UTC (permalink / raw) To: grarpamp; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3498 bytes --] By the way, I have a download of the Bitcoin-Qt client and signature verification running in a cron job. On Thu, Apr 4, 2013 at 10:11 AM, Mike Hearn <mike@plan99•net> wrote: > My general hope/vague plan for bitcoinj based wallets is to get them all > on to automatic updates with threshold signatures. Combined with regular > audits of the initial downloads for new users, that should give a pretty > safe result that is immune to a developer going rogue. > > > On Wed, Apr 3, 2013 at 7:12 PM, grarpamp <grarpamp@gmail•com> wrote: > >> > Users will have available multisig addresses which require >> > transactions to be signed off by a wallet HSM. (E.g. a keyfob >> >> Hardware is a good thing. But only if you do the crypto in the >> hardware and trust the hardware and its attack models ;) For >> instance, the fingerprint readers you see everywhere... many >> of them just present the raw fingerprint scan to the host (and >> host software), instead of hashing the fingerprint internally and >> using that as primitive in crypto exchanges with the host. They >> cheaped out and/or didn't think. So oops, there went both your >> security (host replay) and your personal privacy (biometrics), >> outside of your control. All with no protection against physical >> fingerprint lifting. >> >> > This doesn't remove the need to improve repository integrity. ... but >> > repository integrity is a general problem that is applicable to many >> > things (after all, what does it matter if you can't compromise Bitcoin >> > if you can compromise boost, openssl, or gcc?) >> >> Yes, that case would matter zero to the end product. However >> having a strong repo permits better auditing of the BTC codebase. >> That's a good thing, and eliminates the need to talk chicken and >> egg. >> >> > It's probably best >> > that Bitcoin specalists stay focused on Bitcoin security measures, and >> > other people interested in repository security come and help out >> > improving it. An obvious area of improvement might be oddity >> > detection and alerting: It's weird that I can rewrite history on >> > github, so long as I do it quickly, without anyone noticing. >> >> If no one is verifying the repo, sure, even entire repos could be >> swapped out for seemingly identical ones. >> >> Many repos do not have any strong internal verification structures >> at all, and they run on filesystems that accept bitrot. >> Take a look at some OS's... OpenBSD and FreeBSD, supposedly >> the more secure ones out there... both use legacy repos on FFS. >> Seems rather ironic in the lol department. >> >> Thankfully some people out there are finally getting a clue on these >> issues, making and learning the tools, converting and migrating >> things, working on top down signed build and distribution chain, etc... >> so maybe in ten years the opensource world will be much farther >> ahead. Or at least have a strong audit trail. >> >> >> ------------------------------------------------------------------------------ >> Minimize network downtime and maximize team effectiveness. >> Reduce network management and security costs.Learn how to hire >> the most talented Cisco Certified professionals. Visit the >> Employer Resources Portal >> http://www.cisco.com/web/learning/employer_resources/index.html >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > [-- Attachment #2: Type: text/html, Size: 4600 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2013-04-04 10:04 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-01 8:26 [Bitcoin-development] bitcoin pull requests Melvin Carvalho
2013-04-01 18:28 ` Petr Praus
2013-04-01 21:52 ` Melvin Carvalho
2013-04-01 22:10 ` Will
2013-04-01 22:27 ` Melvin Carvalho
2013-04-01 22:51 ` Roy Badami
2013-04-01 22:54 ` Roy Badami
2013-04-03 3:41 ` Wladimir
2013-04-03 3:51 ` Jeff Garzik
2013-04-03 15:52 ` grarpamp
2013-04-03 16:05 ` Gavin Andresen
2013-04-03 16:23 ` grarpamp
[not found] ` <CAAS2fgT06RHBO_0stKQAYLPB39ZAzaCVduFZJROjSzXUP4Db+g@mail.gmail.com>
2013-04-03 18:12 ` grarpamp
2013-04-04 9:11 ` Mike Hearn
2013-04-04 10:04 ` Mike Hearn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox