Darknet Messenger Briar Releases Beta, Passes Security Audit
briarproject.org
briarproject.org
I do wonder what plans are in place for migrating user data and identities - of all electronic devices, the one most likely to be lost, stolen, broken has to be the phone - and it's not really great if loss of the device means loss of access to the network and built-up web-of-trust.
I see there's a mechanism to introduce contacts to each other - perhaps that could be implemented (technically) similar to pgp key signing/web-of-trust - that would still require a means to backup ones secret key, in order to regain access though.
if they changed the code and design after the audit, then much worse bugs might be hiding now, until that version is audited.
There are certain certifications with falsifiable conditions that can be marked pass/fail. But, as I'm sure many folks here are aware, these are incomplete and often completely dubious. They don't purport to be "security audits".
What a real security audit tells you is that of the (probably 2-4) consultants that looked at a product for a few weeks (probably 2-6), these were the security bugs they found.
That alone contains little information, because the skill level and domain expertise varies greatly among consultants and companies. I can guarantee that if these results were withheld, and they gave the same codebase to another reputable outfit, the set of findings would be very different. There would likely be some overlap, particularly in the most obvious types of bugs, but bug hunting is way closer to art than science.
I know nothing about this project, and my intent is not to create doubt, but users of secure messaging apps should understand what an audit is and what it isn't.
Like other commenters, I was surprised to see 3 days of looking at crypto. It could be that the crypto is extremely simple and uses a few well understood APIs in a straightforward way, so this isn't a guaranteed red flag by any means, but it's a bit unusual.
And like any software, this is a 1 line patch away from being blown wide open. With every commit, an audit becomes increasingly meaningless. Just ask cperciva!
And perhaps I'm being cynical, but I always felt like the "conclusions" section of the audit report has an unspoken purpose of walking back from calling their baby ugly and keeping a decent rapport to ensure the possibility of future business. Not that I think what Cure53 wrote was not genuine, but there are natural incentives to be a little generous there. Again, I'm speaking from experience writing those sections as well.
Edit: Basically what tptacek said.
The focus is on a time window based hash derivation of keys for symmetric cryptography and tags to recognize streams. It currently uses blake2s and XSalsa20/Poly1305. Bouncy Castle is used for the core algorithm implementations when possible.
Connections are made via QR code and use ECDH with cofactor multiplication. There is also a simple bittorrent-inspiried synchronization level that is new and an encrypted storage layer for data storage (I'm not sure but I think this may use pre-existing code).
So there is some amount of crypto to look at but it is fairly basic and not doing anything exotic. The layering and heavy use of symmetric crypto makes the crypto simpler than might be expected based on the features (and battery use heavier).
Version 1 of anything is likely to have issues and hopefully even the release will have a disclaimer to that effect, but there is always a tradeoff between needing some amount of support for further development and trying to make the best app possible before releasing. Briar has been in development for years and they are aware of that tradeoff and trying to both be cautious and not allow the project to die from lack of usable result.
The transport layer spec is at: https://code.briarproject.org/akwizgran/briar-spec/blob/mast...
QR code based key exchange spec is at: https://code.briarproject.org/akwizgran/briar-spec/blob/mast...
Sychronization layer spec is at: https://code.briarproject.org/akwizgran/briar-spec/blob/mast...
The authorities probably just have to flip a switch to put you under closer surveillance if they see you use Tor. Or they'll just send someone to your registered address and see whats going on.
What I really think would be cool would be a protocol based on massive steganography and obfuscation. You would have kernels which tell it how to wrap data in an innocent looking container (HTTPS traffic, SMT, IRC, Cat pictures and recipies over plain HTTP, DNS, ICMP pings, ...). Ideally, you would have dozens. And they would be shareable between nodes. You could define them in a DSL, and make them sandboxed and provable (that they round-trip, i.e. can decode what they encode, and terminate properly - that restricts what you can do in them though). You could even autogenerate the kernels. The last two points would require a bit of R&D of course.
The goal would be to be able to create new "protocols" faster than authorities can learn to detect them. Then wrap a regular encrypted protocol in this obfuscation layer.
Also, you would have dozens or hundreds of kernels, and you could generate them by analyzing innocent traffic, or hiring a bunch of students to write them quickly. My idea is that the kernels are not part of the source code per se, but rather distributed by the protocol. To contact somebody you need to speak a common kernel, but then they can send you new kernels automatically. You could come up with a measure of how well kernels survive censorship and use that to decide which to pass on.
It's a bit like auto updating malware, but for good :-). My only novel idea is to make a DSL or bytecode for the kernels, so that you can prove that they are benign and correct, and autogenerate them or use kernels from strangers. I don't know at all if this is feasible or not, but I have a couple of ideas how to make it work. No where near a POC yet so this is all still wishful thinking though.
In such an environment, the traffic of suspected activists will be analyzed.
Assuming the kernels are open, it's possible to see in analysis of certain data that "amounts of spaces in text files, in the least significant bits of pixels in images, or in the access pattern to a certain service" have encoded information, even if the extracted information looks like random/encrypted data. At this point you don't have plausible deniability and rubber hose cryptoanalysis can be used.
Switching to new kernels happens too late since you don't know when they've identified a kernel until they start arresting people - it's not like they're simply going to block it immediately.
i.e., the described service is resistant to mass censorship and automated filtering, but these use cases actually need to be able to resist attribution and retaliation, which are quite different problems.
Maybe allow copying/pasting keys but with a Signal-style post-validation or something like a PGP wordlist to allow voice-based confirmation?
I've done this for roughly five years.
Assuming I've never wanted to become a Debian developer, is there any important piece of privacy-preserving software I've missed out on? Is there likely to be any important privacy-preserving software I will miss out on in the next five years?
Edit: clarification
Bitcoin - used PKI to download it. Now Bitcoin is reproducibly buildable, so you can read the forum to see if any zealots notice different hashes (which they certainly would unless you are personally being targeted in testing out the software). Make some small transactions to see if it works.
Bitmessage - downloaded it a few days after the initial release. Sent a message over Bitmessage to the Bitmessage author. Got one back from the author.
Tor - trust that the directory servers are doing their jobs.
Signal - haven't used it but if I did I'll piggy-back on phone numbers to message people I already know.
git - used PKI to initially grab the code, trust my own dev machine as I've made commits, occasionally posted commit hashes over various secure/insecure mediums for various reasons (may have done this in person wrt a bug, can't remember).
Notice that in all these cases, trying out the software (at least in the U.S.) does not at all imply that you trust it. You could practice installing Tor 20 different times, on 20 different untrustworthy Windows machines and simply use it to search for cat pictures. Then, the 21st time, you could take all kinds of precautions and build a special box just for running Tor, armed with all the first-hand knowledge about how it works and what its trade-offs are.
I can also completely fuck up something in git and get so frustrated I just clone it again from the repo I don't have to trust because I just check the hashes and go on working.
Requiring physical proximity and a formal key exchange before I can even use the software simply cannot work IMO. It a) requires special planning, coincidence, or proselytization to try out a working version of the app, b) it balloons the length of the engineering cycles and makes it hard to just start over, c) the reliance on in-person meeting implies a level of trust between you, your keys, and your smartphones that neither party should take for granted.
Also, it doesn't scale.
What is surprising to me is that so little of that time was devoted to cryptography. For a secure messenger that time should be ratcheted up a bit (though the security infrastructure and general software implementation stuff is also very important).
You may say that a tool/network/protocol is decentralized and/or secure and/or anonymous and/or censorship-resistant and/or routed through Tor and/or doesn't leak identity and/or tamper-resistant and/or has plausible deniability etc etc and all these labels would mean something - "darknet" does not.
A "darknet messenger" might tick any set of these boxes, but the meaning is completely different depending on which of these labels apply.
unless you think providing Bluetooth is "darknet" .
But you have to admit there are connotations and that leads to bias when you start talking to laypeople who don't understand the other meanings or usages of 'darknet' or 'hacker'. There may be better ways to communicate that won't immediately stop the general public in their tracks when they hear a particular 'tainted' word.
Side note: Is there a way to export (basically archive offline) the content; to be clear only one's content, not someone else's? I'd hate to have some important messages lost if I were to lose my phone. Not saying i want a central server...simply some method to archive my own stuff for safe keeping - encrypted of course.
Otherwise, briar seems really awesome!
I'm glad I took a peek. This is actually interesting to me.
...Briar is a secure messaging app for Android.
Unlike other popular apps, Briar does not require servers to work. It connects users directly using a peer-to-peer network. This makes it resistant to censorship and allows it to work even without internet access.
The app encrypts all data end-to-end and also hides metadata about who is communicating. This is the next step in the evolution of secure messaging. No communication ever enters the public internet. Everything is sent via the Tor anonymity network or local networks.
I've looked through a lot of the documentation and can't find anything other than references to bluetooth and wi-fi, which is opaque to me.
I'm kind of wondering about something like briar, but that can connect over a cjdns network if available... is that what it's doing?
Money quote from a tox dev: "Tox provides some strong security guarantees. We haven't got to the point where we can enumerate them properly, given the general lack of understanding of the code and specification."
I'm not a crypto expert, but I also personally wouldn't put much stock in the security of their protocol or implementation.
A pentest consists of an analysis period, typically about a week. Then any flaws in your app are communicated to you, along with steps to reproduce them. When you feel you've fixed the issues, a retest is scheduled and the pentesters verify that each flaw has been fixed.
A healthy application is one that's pentested on a regular basis. Ideally after every release, though only big companies can afford that.
I see, that's a good point I hadn't considered.
That was one of the most heavily audited components too.
"Audits" and "passing" make some sense for network security, where you can run a checklist of best practices and known vulnerabilities. But you can't really "audit" source code in the same sense, any more than you can contract someone to spend 2 weeks finding all the sev:hi crashers or data loss bugs in your database.
It would be good if organizations could stop pretending that "passing" a software security assessment was meaningful.
What you really want to know is how many person/days Cure53 spent on Briar, who Cure53 had staffing the engagement, what the scope of the engagement was (what components were off limits), and whether they found anything that was subsequently fixed (it's an industry secret that one of the reasons you do an audit is so you don't have to publish the "real" findings).
From the report, it looks like they spent 13 calendar days testing (it's not clear how many person/days were spent), of which only 3 were dedicated to cryptography, and the audit was constrained to the Android clientside code.
For perspective: the "industry standard" software pentest of a reasonably complicated web application is 2 people, 2 weeks.
I mostly hear it used to mean what it is supposed to mean, but that is rarely from non-technical people.
Darknet now: Anonymous place drugs sometimes happen
Darknet if it becomes bigger: That place where terrorists and criminals hide, the FBI and NSA say it's a risk to national security and we have to stop it at all costs! What do you mean it's just a secure messaging app? I'm not a terrorist, I don't need anything like that!
Look at Tor.