Bitcoin Forum
May 25, 2024, 01:40:45 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3]  All
  Print  
Author Topic: Can the U.S. government meddle with BitCoin code?  (Read 5286 times)
sickpig
Legendary
*
Offline Offline

Activity: 1260
Merit: 1008


View Profile
April 12, 2014, 01:16:19 PM
 #41

Since anyone can download and read the code how would they do this?

They could've modified the downloadable binary and force a dev to sign the compiled binary so that it looks legit. Not sure how fast a slight modification would've been noticed this way.

Checking the code and diffing it with previous releases would show nothing nefarious, and compiling from source and comparing it to the released binary might as well not work very well, as I guess different environments have different build environments and builds will be slightly different unless environments are duplicated exactly?

So the change in the binary might for instance allow siphoning of private keys to an adversary. And if the adversary was careful, stealing of coins could go on slowly as not to raise too much suspicion, or it could be used to just control bitcoin addresses, and then freeze them once it's necessary. Ie. 'freezing' it by transferring coins using the stolen private keys.

I don't know if there currently is any process whereby the binaries released are checked by several parties before they're ok'ed. The Sha256 checksums and pgp signature only proves that the holder of that signature has vouched for those checksums.

There should ideally be some 'paranoid bitcoin' project, or better yet several of them serving as watchdogs alerting the larger community once something nefarious happens.

Ideally to stay safe, one should always diff a new release against a previous release by checking what code is added, then understand this code and ensure nothing nefarious has been added, and then compile it yourself.

But how could one be sure that eventually sometime some distributor of a linux system doesn't distribute it with a compiler that will insert some nefarious code once it discovers that a bitcoin binary is being made.

There's a lot of trust we need to place in other people - and if you become too paranoid, you could worry about details all day long.

Any comments to this ? ^^

From the lwn.net article "binary diversity"

Quote
There's been a lot of talk about reproducible (or deterministic) builds recently for the purposes of verifying that binaries come from the "right" source code.

See:

https://lwn.net/Articles/565113/
http://gitian.org

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
sickpig
Legendary
*
Offline Offline

Activity: 1260
Merit: 1008


View Profile
April 12, 2014, 04:24:53 PM
 #42

Now that I think about it bitcoin deb packages are already built using gitian

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
tl121
Sr. Member
****
Offline Offline

Activity: 278
Merit: 252


View Profile
April 12, 2014, 05:11:06 PM
 #43

Quote
Since it is mathematically impossible to recover the input text from the hash of that input text what exactly do you mean by a "back door" to a hashing function?  Exactly what information could a back door give you once the hash is calculated?

A back door would make it easier to find a preimage of a given target then brute force searching through the complete space.  The existence of multiple pre-images (hashing) vs. single preimage (encryption) does not fundamentally change the situation. As an example:  if 512 bits are hashed into 256 bits there will be roughly 2^256 preimages out of the total search space of 2^512 possibilities that hash to a given target. Guessing at random it would take approximately 2^256 trial hashes to find one preimage. With a "back door" it might be possible to substantially reduce this, possibly down to a fairly small number.
johnyj
Legendary
*
Offline Offline

Activity: 1988
Merit: 1012


Beyond Imagination


View Profile
April 12, 2014, 08:00:43 PM
 #44

The rule of thumb is never upgrade clients if unecessary, I'm still running 0.8.5.

The modularization is a very important step into distant future, so that future core protocol upgrade will mostly be impossible unless a consensus is reached by majority or miners

Honeypot
Sr. Member
****
Offline Offline

Activity: 420
Merit: 250


View Profile
April 12, 2014, 11:20:29 PM
 #45

The weak link is always the human factor - as in, governments, the mob, or anyone else may not fully control the tech, but they can most definitely control the ones using it.

As far as real power goes, your tech won't save you from a five buck wrench giving you a new set of dentals.


Keep it fuckin real people. Also, the fuck are you doing saying 'US Government' when it's the chinese that's doing the most banning and hating on bitcoin since the time it got big?

Get your fucking priorities straight. All the knee jerk squealing and bitching about 'EBIL US GOVERNMENT' is fuckin pathetic, ESPECIALLY when you don't even bitch half as much on another government that's ACTUALLY squashing crypto and trying to grab the entire market by the balls.

Or maybe you are just that easily manipulated.
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
April 13, 2014, 04:19:18 AM
 #46

they already have.
SHA-256 is NSA child


if the NSA could use heartbleed for anything useful, then why did they need to contact google to get DPR's emails. why did they then contact the UK's GCHQ to brute force password break DPR's files??

Because the NSA are not as great as they claim. so chill out.

NSA dont have a backdoor into sha256

So they have people like you thinking they don't have the original backdoors and use them.
They can be evil and corrupt but not dumb.
Since it is mathematically impossible to recover the input text from the hash of that input text what exactly do you mean by a "back door" to a hashing function?  Exactly what information could a back door give you once the hash is calculated?

That's what I'm asking as well... No one is giving any answers.... Cryptography experts jump in please.  Any documented backdoors in any cryptographic hashes, ever? 



lol
its not like that: //backdoor code here
it could be a vulnerability that got fix or a code that was designed to appear as a bug.

Any examples though?

backdoors in OpenBSD's IPSec stack inserted by a FBI contractor.

Googled this... Thanks for the example.  But this doesn't even appear to be in the same ballpark. 
OpenBSD is apparently a "unix like operating system", and then you have an entire stack involving
The IPSec layer.  We're taking a pretty complex library of code here..... VERY different from cryptographic
Hash function such as SHA-256 that can be implemented in a few dozen lines of code....

Not even really the same animal at all when you think about it...  A backdoor to the hash function
Itself, if possible, would have to be accomplished at the mathematical/theoretical level...which
Is really my question to the mathematicians and cryptographers out there.  Is THAT possible?



It was an example... as far as cryptographic backdoors, we'll never know for sure because its at hardware level now, google 'Intel In Bed with NSA'.


Not with bitcoin though obviously

TheFootMan
Hero Member
*****
Offline Offline

Activity: 490
Merit: 500


View Profile
April 13, 2014, 08:15:00 PM
 #47

Or maybe you are just that easily manipulated.

Or maybe it's just another discussion thread on a forum really leading nowhere but discussing a topic of interest to the participants. If you look at this forum, at least 70% is noise.
rohan1
Newbie
*
Offline Offline

Activity: 40
Merit: 0


View Profile
April 14, 2014, 10:09:31 AM
 #48

Without China or U.S, the bitcoin world can still continue grow up in application, this trend will not change.
so I don't believe Bitcoin will give in on the coding.
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!