Pages:
Author

Topic: Can the U.S. government meddle with BitCoin code? (Read 5326 times)

newbie
Activity: 40
Merit: 0
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.
hero member
Activity: 490
Merit: 500
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.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
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
sr. member
Activity: 420
Merit: 250
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.
legendary
Activity: 1988
Merit: 1012
Beyond Imagination
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
sr. member
Activity: 278
Merit: 254
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.
legendary
Activity: 1260
Merit: 1008
Now that I think about it bitcoin deb packages are already built using gitian
legendary
Activity: 1260
Merit: 1008
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
hero member
Activity: 490
Merit: 500
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 ? ^^
legendary
Activity: 888
Merit: 1000
Monero - secure, private and untraceable currency.
i know 99% have simply downloaded the .exe and not even be bothered to check the code, in the hopes that someone smarter will check it and tell people to downgrade back to version 0.8x if something nasty was in the code.

make that 99.999999999% .... what i'm most affraid of is intentional bugs that can be found easily even if many geeks are looking to it...
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
Back to the idea of a weakness in a hash function:  if you have a hash it is impossible to get back to the original text simply because by necessity and design there are always MANY input texts that hash to the same value. 
hero member
Activity: 770
Merit: 500
Until they are outside US, no chance
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo
Quote
Is really my question to the mathematicians and cryptographers out there.  Is THAT possible?

Theoretically, yes. An 'error' in an arcane statistical method deep into long-winded technical RFC paper could get missed that makes the method weak in just the right amount in a known location.

Other people can say it better https://www.schneier.com/essay-472.html
Quote
The third is the deliberate sabotaging of security. The primary example we have of this is the NSA's BULLRUN program, which tries to "insert vulnerabilities into commercial encryption systems, IT systems, networks and endpoint communication devices." This is the worst of the NSA's excesses, because it destroys our trust in the Internet, weakens the security all of us rely on and makes us more vulnerable to attackers worldwide.
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
SHA256 is a cryptographic hash function.

Secp256k1 is the elliptical curve used by Bitcoin.

They are not related in any way shape or form.

Two different subjects.
sr. member
Activity: 378
Merit: 255
There is suspicion in secp256r1 that the NSA recommends a seemingly random values to use as your pseudorandom seed.  Satoshi chose different values instead.

Look at this article:

http://bitcoinmagazine.com/7781/satoshis-genius-unexpected-ways-in-which-bitcoin-dodged-some-cryptographic-bullet/
Quote from: Bitcoin Magazine
For secp256r1, the standard 256-bit pseudorandom curve, the seed is c49d360886e704936a6678e1139d26b7819f7e90, giving rise to the parameters:

p = 115792089210356248762697446949407573530086143415290314195533631308867097853951
a = 115792089210356248762697446949407573530086143415290314195533631308867097853948
b = 41058363725152142129326129780047268409114441015993725554835256314039467401291

The obvious question is this: where did the seed come from? Why was the seed not chosen to be some more innocent-looking number, like 15? In light of recent revelations regarding the US National Security Agency subverting cryptographic standards, an obvious concern is that the seed was somehow deliberately chosen in order to make the curve weak in some way that only the NSA knows.

If the NSA knows of an elliptic curve vulnerability that affects only one specific curve, the pseudorandom parameter generation process would prevent them from standardizing it. However, if they knew of a weakness in one in every billion curves, then the process offers no protection; for all we know, c49d360886e704936a6678e1139d26b7819f7e90 could have been the billionth seed that the National Institute for Standards in Technology tried.

Fortunately, Bitcoin does not use pseudorandom curves; Bitcoin uses Koblitz curves. In Bitcoin’s secp256k1, the parameters are:

p = 115792089237316195423570985008687907853269984665640564039457584007908834671663
a = 0
b = 7


Read the whole thing, it's really a great read.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
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?

legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
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?
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
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? 

legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
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?
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
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.

Do you have any evidence of this?  indeed,can anyone provide any example of a backdoor to an opensource cryptographic hash function?  Does such a thing exist?
Pages:
Jump to: