Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Briar Project

briarproject.org

Post reply on HN
Print view View original

171–180 of 189 posts

Re: Briar Project

#171

Post by fiddlerwoaroof »

fiddlerwoaroof wrote: post #161
Arathorn wrote: post #160

Earlier quoted context omitted.

there aren't downgrade attacks. we turned on E2EE by default in May for private rooms, and there's no negotiation involved. if you're on a client that supports E2EE (i.e. almost all major ones, now) and you try to DM someone, they simply won't be able to read you unless they support E2EE. i.e. they can't downgrade the convo.

Yeah, I really like the ability to have an unencrypted channel: easy bots and bridges are one of the main advantages for me of matrix vs. IRC. My only big issue is that the iOS client doesn’t support multiple simultaneous identities.

I should have said “easy bots and bridges are one of the main advantages for me of matrix as a successor to IRC”

Re: Briar Project

#172

Post by maqp »

Arathorn wrote: post #160
maqp wrote: post #148

Earlier quoted context omitted.

If only the ecosystem had been built to use E2EE by default, always. They fucked up with the design allowing bridges and bots, left E2EE for later, and now they're in the vicious circle of downgrade attacks until all major clients switch to E2EE with no insecure fall-back option.

there aren't downgrade attacks. we turned on E2EE by default in May for private rooms, and there's no negotiation involved. if you're on a client that supports E2EE (i.e. almost all major ones, now) and you try to DM someone, they simply won't be able to read you unless they support E2EE. i.e. they can't downgrade the convo.

That's good. The last time I had a look at Matrix clients it was a mess. IIUC the E2EE isn't enabled by default for the old Riot client, only RiotX and Riot web have it.

What happens if someone with old Riot client creates a room and someone with e.g. RiotX joins it, will it force E2EE on? Or will it fall back to non-E2EE messaging?

Re: Briar Project

#173

Post by maqp »

foresto wrote: post #170
maqp wrote: post #146

Earlier quoted context omitted.

"some way to protect metadata (e.g. self-hosting)" is incompatible with Wire. Let's not just scream product names without understanding if it's for their threat model. If you're here to promote Wire then I perfectly understand why you'd recommend it anyway.

Yeah, Wire failed my requirements, but I probably should have mentioned it. (I simply forgot about it when I was posting.) There's the issue you mentioned, and there's also the issue of them violating their published policy (either by the letter or in spirit) when they accepted new owners/investors.[1] Even if it met my requirements, I would be leery, and reluctant to suggest that others invest their time and build t…

"when they accepted new owners/investors."

IMHO we should be able to determine the amount of trust we can put on the app from the client alone. If FOSS client uses E2EE, no matter what the server starts doing when the service changes ownership will have an effect on it. Of course the new owner could e.g. start selling user metadata, but that's something you should kind of assume the service is doing anyway (just because they can), and if you can't take the risk, you should use something that prevents it by design (like Briar/Cwtch/Ricochet/TFC).

Re: Briar Project

#174

Post by maqp »

Legogris wrote: post #149
maqp wrote: post #139

Earlier quoted context omitted.

Quick unrelated comment from the peanut gallery: Every time any crypto-currency related messaging app is published, I think it should be mandatory to immediately explain what the currency and/or blockchain brings to the table. Is it a paid app? Does it store ciphertexts indenfinitely to the blockchain? Or public keys?

While I understand where you're coming from, Status is an interesting project even if you completely disregard their (IMO shoehorned utility-) token. The main thing they have right now is an app acting as a wallet (ETH and Ethereum-based tokens) and IM app (Whisper protocol). It's standard practice that what you request is answered in a whitepaper, which is also the case for Status: https://status.im/whitepaper.pdf

Jesus Christ, that must be fourth or fifth "whitepaper" I see from the cryptocurrency community. Here's what a proper whitepapers should look like:

https://signal.org/docs/specifications/x3dh/x3dh.pdf

https://signal.org/docs/specifications/doubleratchet/doubler...

Status' whitepaper looks like marketing material for investors, not a technical description for infosec professionals. I find the content almost repulsive.

Re: Briar Project

#175

Post by foresto »

maqp wrote: post #173
foresto wrote: post #170

Earlier quoted context omitted.

Yeah, Wire failed my requirements, but I probably should have mentioned it. (I simply forgot about it when I was posting.) There's the issue you mentioned, and there's also the issue of them violating their published policy (either by the letter or in spirit) when they accepted new owners/investors.[1] Even if it met my requirements, I would be leery, and reluctant to suggest that others invest their time and build t…

"when they accepted new owners/investors." IMHO we should be able to determine the amount of trust we can put on the app from the client alone. If FOSS client uses E2EE, no matter what the server starts doing when the service changes ownership will have an effect on it. Of course the new owner could e.g. start selling user metadata, but that's something you should kind of assume the service is doing anyway (just beca…

I agree in principle, and I look forward to the day when all my requirements can be met without self-hosting or trusting another party with metadata. After all, most people don't have the means to self-host. Multiple projects (including Matrix) are working in that direction, but I'm not holding my breath; metadata exists at multiple layers, and is a hard problem to solve.

Until that day, a public host with the right incentives and track record remains valuable, even if only to include people who don't have tech-savvy friends to host for them.

Regardless of all that, given the choice between rewarding an organization with good behavior vs. one with bad behavior, I choose the former.

Re: Briar Project

#176

Post by maqp »

foresto wrote: post #168
maqp wrote: post #138

Earlier quoted context omitted.

"some way to protect metadata (e.g. self-hosting)" From whom are you trying to protect metadata? Briar distinguishes itself as a platform that doesn't leak it to anyone. Matrix always has at least one central point for metadata eavesdropping, and that's the device the entities interested in your communication will hack first. Or maybe the threat of the group is in the inside -- John, the creepy IT-guy of the peer net…

I think it's important to distinguish mass surveillance from targeted surveillance. They present very different threat models. I need a general-purpose chat tool for use with friends, family, and business contacts. Protection from targeted surveillance by a state actor (or someone with equivalent resources) is neither a priority nor realistic today in light of my other requirements. I'm okay with using a separate too…

"I think it's important to distinguish mass surveillance from targeted surveillance. They present very different threat models."

Targeted attacks against centralized points that enable wide-scale surveillance are mass surveillance. Imagine NSA would claim "A fiber optic splitter in the bottom of the ocean is a targeted attack against one device (repeater), or one inch segment of glass wire, it's not mass surveillance".

It's vital that we define targeted surveillance as something where the target is a single entity. Hacking Moxie's phone is targeted surveillance. Hacking Signal server is not. Hacking every visitor of a CP site is mass surveillance https://www.eff.org/deeplinks/2016/09/playpen-story-fbis-unp...

"You might want to look at their in-progress P2P work."

It will be a nice to have sure, but I think P2P should work exclusively via Tor if you want to hide metadata. wrt that, you might find my work interesting https://github.com/maqp/tfc

"Briar fails unless you only talk to people using smartphones."

A picture is worth a thousand words

https://twitter.com/Amlk_B/status/1286642831239647232/photo/...

"MoxieTalk fails because it exposes people to mass surveillance."

Jabs like these aren't really appreciated. Extraordinary claims require extraordinary evidence.

Re: Briar Project

#177

Post by fiddlerwoaroof »

maqp wrote: post #172
Arathorn wrote: post #160

Earlier quoted context omitted.

there aren't downgrade attacks. we turned on E2EE by default in May for private rooms, and there's no negotiation involved. if you're on a client that supports E2EE (i.e. almost all major ones, now) and you try to DM someone, they simply won't be able to read you unless they support E2EE. i.e. they can't downgrade the convo.

That's good. The last time I had a look at Matrix clients it was a mess. IIUC the E2EE isn't enabled by default for the old Riot client, only RiotX and Riot web have it. What happens if someone with old Riot client creates a room and someone with e.g. RiotX joins it, will it force E2EE on? Or will it fall back to non-E2EE messaging?

The creator and admins of the room picks the encryption preferences, iiuc: if you have a client that doesn’t support E2EE, you might be able to create an encrypted room (?) but it would be pretty useless. The clients all clearly mark the encryption status of the room you’re in.

Re: Briar Project

#178

Post by michaelsbradley »

maqp wrote: post #174
Legogris wrote: post #149

Earlier quoted context omitted.

While I understand where you're coming from, Status is an interesting project even if you completely disregard their (IMO shoehorned utility-) token. The main thing they have right now is an app acting as a wallet (ETH and Ethereum-based tokens) and IM app (Whisper protocol). It's standard practice that what you request is answered in a whitepaper, which is also the case for Status: https://status.im/whitepaper.pdf

Jesus Christ, that must be fourth or fifth "whitepaper" I see from the cryptocurrency community. Here's what a proper whitepapers should look like: https://signal.org/docs/specifications/x3dh/x3dh.pdf https://signal.org/docs/specifications/doubleratchet/doubler... Status' whitepaper looks like marketing material for investors, not a technical description for infosec professionals. I find the content almost repulsive.

https://specs.vac.dev/specs/waku/waku.html

Waku is in R&D by Status.

Re: Briar Project

#179

Post by Legogris »

maqp wrote: post #174
Legogris wrote: post #149

Earlier quoted context omitted.

While I understand where you're coming from, Status is an interesting project even if you completely disregard their (IMO shoehorned utility-) token. The main thing they have right now is an app acting as a wallet (ETH and Ethereum-based tokens) and IM app (Whisper protocol). It's standard practice that what you request is answered in a whitepaper, which is also the case for Status: https://status.im/whitepaper.pdf

Jesus Christ, that must be fourth or fifth "whitepaper" I see from the cryptocurrency community. Here's what a proper whitepapers should look like: https://signal.org/docs/specifications/x3dh/x3dh.pdf https://signal.org/docs/specifications/doubleratchet/doubler... Status' whitepaper looks like marketing material for investors, not a technical description for infosec professionals. I find the content almost repulsive.

> Status' whitepaper looks like marketing material for investors

TBF, that is the more commonly understood meaning of "white paper".

https://en.wikipedia.org/wiki/White_paper#In_business-to-bus...

Re: Briar Project

#180

Post by benhurmarcel »

maqp wrote: post #146
benhurmarcel wrote: post #130

Earlier quoted context omitted.

You might want to look at Wire https://wire.com/

"some way to protect metadata (e.g. self-hosting)" is incompatible with Wire. Let's not just scream product names without understanding if it's for their threat model. If you're here to promote Wire then I perfectly understand why you'd recommend it anyway.

I have nothing to do with Wire, I just thought it was close enough to his requirements that he would benefit knowing about it.
Post reply on HN