71–80 of 112 posts
Earlier quoted context omitted.
There would be no assurance that the binary is compiled from the source though.
And even if it were, http://cm.bell-labs.com/who/ken/trust.html
Earlier quoted context omitted.
That's a pretty old thread. They've made a lot of progress since then.
What i don't see (maybe haven't looked hard enough) are another security review/s. Until bitmessage is thoroughly reviewed by serious people ,and results are displayed in a prominent place, it would be hard to trust.
From the homepage: Bitmessage is in need of an independent audit to verify its security.
Earlier quoted context omitted.
Actually, there has been some recent research [0] in cryptography that shows it is possible to produce binaries that are obfuscated in such a way such that they are computationally infeasible to deobfuscate (see the linked reference for a formal definition of indistinguishability obfuscation). [0] - http://eprint.iacr.org/2013/451.pdf
Yes. Even more simply, it is an impossible problem in the general case to even determine in a given x86 binary what parts are code and what parts are data (there was someone at RV '04 that published a paper on that result while working on his CodeSurfer binary analysis tool). This does not, however, contradict my argument: as we can take a binary and generate really horrible C code from it (by just emulating via C, u…
Personally, I'm running BTSync - and even though I've got it syncing EncFS encrypted data, the app has enough privileges to read the unencrypted versions of those EncFS filesystems if it were instructed to.
I'd feel happier if a few trusted security experts from a few different countries/jurisdictions had blogged about their analysis of the source code and the likelyhood of the binary produced from the source being either intentionally or unintentionally compromised.
Having said that, as you point out, we've got the Chrome source, lots of people look very hard at it, and it _still_ fails year after year… Hopefully, BTSync and BTChat (or my hypothetical Open Source reimplemetations) are significantly less complex than a full featured browser, and not would not require nearly so much focus on performance that "provably secure" or perhaps just "significantly less likely to have obscure bugs" coding techniques could be used in spite of speed penalties - browser vendors have significant motivation to optimise for speed above all else, hopefully the much smaller subject domains of sync or chat clients would allow security to sensibly be prioritised instead.
Earlier quoted context omitted.
It is possible to analyze the behavior of a program without access to the source code that makes it easy to recompile and distribute modified builds. I routinely open binary files in disassemblers to read through their behavior. Yes, it is possible to obfuscate the hell out of parts of binary code, and that would certainly throw up a red flag for me, but concentrating on the source code seems to miss the point that s…
Your argument is a bit disingenuous. You say you'd trust simple closed-source software more than complicated open-source counterparts. That's a false dichotomy. Open source X is always more easily auditable than closed source X. I don't think many people are worried that BT will be evil. I think many more people are worried that they'll be incompetent, and it's very hard to be competent at cryptography. That's why we…
Company Overview
BitTorrent Inc. is an Internet technology company based in San Francisco.
If you're a US company (or individual, or a company with US based management, developers, investors, or infrastructure) who are promoting security-related products in the post-Snowden era – many of us outside the US now have very good reasons to apply extra scrutiny to those products. Opening your source will make a _big_ difference in how readily suspicions of evilness can be allayed. As saurik points out upthread, having the source available doesn't guarantee the rest of the open source community will find and fix any carefully-enough-crafted backdoors, but keeping the source closed sends a strong message…
Earlier quoted context omitted.
Sure, it's only one variable. I disagree that it's not the most important one. You can audit a multithreaded open source program much more easily than you can audit a single-threaded closed source program. Merely compiling it adds more obfuscation than making it needlessly, complicated will, and making it needlessly complicated will immediately raise red flags. You don't need to analyze an open-source program to see…
> You can audit a multithreaded open source program much more easily than you can audit a single-threaded closed source program. I think this is our core disagreement, as I've been pretty clear about how I don't just accept this statement at face value given the large class of subtle bugs that can and do occur constantly in multi-threaded systems. I find reading through and finding bugs in complex binary-only buffer-…
Earlier quoted context omitted.
Sure, it's only one variable. I disagree that it's not the most important one. You can audit a multithreaded open source program much more easily than you can audit a single-threaded closed source program. Merely compiling it adds more obfuscation than making it needlessly, complicated will, and making it needlessly complicated will immediately raise red flags. You don't need to analyze an open-source program to see…
> You can audit a multithreaded open source program much more easily than you can audit a single-threaded closed source program. I think this is our core disagreement, as I've been pretty clear about how I don't just accept this statement at face value given the large class of subtle bugs that can and do occur constantly in multi-threaded systems. I find reading through and finding bugs in complex binary-only buffer-…
Easy and time consuming are mutually exclusive in this context. It's about cost, and time is money. Its hard in the sense that the traveling salesman problem is hard, even if the logic for the naive solution is straightforward.
Earlier quoted context omitted.
> You can audit a multithreaded open source program much more easily than you can audit a single-threaded closed source program. I think this is our core disagreement, as I've been pretty clear about how I don't just accept this statement at face value given the large class of subtle bugs that can and do occur constantly in multi-threaded systems. I find reading through and finding bugs in complex binary-only buffer-…
That doesn't sound reasonable. I don't care who you are, auditing the source version is orders of magnitude easier than auditing the binary version. I say this as someone who has been reverse engineering binary code for well over a decade. This doesn't even account for the fact that requiring reverse engineering skill already eliminates the majority of potential auditors, whether due to ability or due to lack of time…
Again, differently, you are again falling into the same problem of looking at this as a "single issue voter": open-source X vs. closed-source X. My complaint is that people go "omg, no source code, I can't trust this" as this knee jerk reaction, as if this is the only variable by which you should be evaluating your potential risks. In the real world, you are going to be comparing using this to other solutions, some open source, some closed source, and attempting to decide which one is more or less secure. Does being closed source affect your guess as to its security? Sure. But does it affect your guess more than some other key variables? I argue not.
That people then outright dismiss something closed source like "lolololololo" are being ludicrously over-simplistic in their view of where security comes from and how people audit systems, and the people like "Karunamon" who decide that it is "suspect", which assigns direct motives to the idea that they are somehow attempting to hide something in their closed source binary, don't understand the threat model.
Other people on this thread, like "bigiain", are even talking about the NSA leaving some kind of detectable backdoor in this closed source binary: that's insane... if the NSA were actually going to leave a backdoor, it wouldn't be something you'd ever look be able to look at, even with complete source code, and realize that it gives them complete control. At best, you'll find it as a "bug", assume it was a "mistake", and fix it, and they'll already have others as backup.
A little disappointing that there's no Linux version and that clicking "Other Platforms + Betas" just takes you to the Windows download. Also it's closed source. Just telling people this so they can save signing up if it's not for them.
I feel like I just signed up for a bunch of spam.