These are chat archives for whereat/contrib

13th
Apr 2016
aguestuser
@aguestuser
Apr 13 2016 00:58
which raises an interesting question (which i've wondered for a while): does signal obscure metadata? can it?
which is related to a separate question:
i'm toying with the idea that we should set the (somewhat audacious) goal of (1) using the signal protocol for our messaging layer and (2) publishing a standalone react native module that interoperates with the signal protocol seamlessly. so that it becomes trivially easy for anyone to build mobile apps with strong end-to-end encryption.
(that are easy to use)
does that sound interesting / fun / exciting / doable?
Meitar M.
@meitar
Apr 13 2016 02:31
I don't think the Signal Protocol obscures metadata from their servers because the client is constantly fetching prekeys, i.e., asking the server "hey, can you get me the pre-key for Bob?" Now the server knows Alice is talking to Bob.
aguestuser
@aguestuser
Apr 13 2016 02:32
right.
Meitar M.
@meitar
Apr 13 2016 02:32
The only way I understand to "obscure" metadata like this is not to rely on a central server, i.e., create a decentralized network so Alice at least has a choice regarding who she sends metadata to.
This is how Jabber/XMPP and OTR work.
(Also one of the reasons behind building Buoy https://gitter.im/betterangels/buoy out as a trivial-to-install plugin for shared hosting/low-power servers, because the hope is that there will be a lot of them.)
aguestuser
@aguestuser
Apr 13 2016 02:35
reading the intercept article now. really great stuff!
Meitar M.
@meitar
Apr 13 2016 02:37
Since that article was published, tools like Tor Messenger and Ricochet have come out that make it much easier to do a Jabber+OTR chat over Tor onion services.
So it's a bit dated. But the principles there are sound and the new tools just (literally) codify that process.
aguestuser
@aguestuser
Apr 13 2016 02:37
we saw a talk on ricochet last month. it was great! @aepyornis actually went. i just got filled in.
Meitar M.
@meitar
Apr 13 2016 02:38
Neat, I'd be interested in that. Any video?
aguestuser
@aguestuser
Apr 13 2016 02:38
so but isn't the problem with OTR (as such) that it doesn't support group chat? which is why group OTR is a standing "difficult problem"?
Meitar M.
@meitar
Apr 13 2016 02:39
Well, Signal Protocol doesn't really support group chat either. The important difference between Signal and OTR is that Signal is store-and-forward, OTR is synchronous-only.
aguestuser
@aguestuser
Apr 13 2016 02:40
How does Signal support group chats if Signal Protocol doesn't?
Meitar M.
@meitar
Apr 13 2016 02:41
I'm pretty sure it's just a clever UI gloss over multiple individual messages getting sent. See: https://whispersystems.org/blog/private-groups/
aguestuser
@aguestuser
Apr 13 2016 02:41
ps... the talk i did go to was about (n+1)sec, which is where i gathered whatever i gathered about group OTR, because they were taking shots at the way signal had implemented group secret sharing...
(pulling link)
this (which is understandable): https://equalit.ie/portfolio/np1sec/
this (which is super mathy): https://learn.equalit.ie/wiki/Np1sec
as i recall (super rusty!) they were doing a different thing with the ratcheting that allowed (1) a group to authenticate only once at the top of the session and renegotiate a shared secret again if anyone left or joined
(2) the ratcheting to be only 1 step ahead (hence n + 1) so that you didn't need to store prekeys anywhere
and thus don't need a server
(which made us super excited!)
except the library only exists in C++ right now. no Java or Objective C bindings... and feels a bit above any of our pay grade
Meitar M.
@meitar
Apr 13 2016 02:44
Huh, yeah, I haven't heard about this one before. Checking out their site now.
aguestuser
@aguestuser
Apr 13 2016 02:45
equalit.ie is cool. same folks who make deflect.ca (rad alternative to cloudflare)
on the bit about by default exposing metadata if you use a (signal-ish) keyserver to facilitate pre-key exchange:
can we imagine an architecture in which we had one server to handle key production, but another transport layer for the actual messages?
(say this only because signal repo as i recall includes their server code... and the docs for sending messages emphasize "use whatever transport layer you like!")
Meitar M.
@meitar
Apr 13 2016 02:50
So, Alice asks server A for Bob's pre-key, but actually sends a message to Bob via server B?
aguestuser
@aguestuser
Apr 13 2016 02:50
yeah. and does that help?
i mean either way you have to trust server A
because it definitely knows all about Alice and Bob being friends
and maintains a record of when they're asking to talk to each other
so if server A is controlled by (say) facebook... bummer...
but if we implemented server A... does that help?
Meitar M.
@meitar
Apr 13 2016 02:52
Well, I guess you could obfuscate that some by asking server A for Tom, Jill, and Harry's keys in addition to Bob's. But now you're kind of talking about a mixnet.
aguestuser
@aguestuser
Apr 13 2016 02:52
if the prekeys i'm asking for are wrapped inside HTTPS traffic (so a passive observer can't detect who's trying to talk to who)...
and the prekeys change every time so sending them over the wire doesn't necessarily reveal an identity...
(by "over the wire" i mean via a relay server B)
Meitar M.
@meitar
Apr 13 2016 02:55
So AFAIK the only reliable way to obscure metadata like this is what Tor's onion routing does. What you're talking about is essentially routing metadata, because prekeys are like addresses.
aguestuser
@aguestuser
Apr 13 2016 02:55
then you have to trust and/or defend server B... (which where@ has thus far gone to great lenghts to avoid having to do). but you get key exchange for (more or less) free.
right, but if the metadata isn't an exposed field in the HTTP request to server A, then it's only exposed to the server. so we haven't obscured it from us (who are running the server). but we have obscured it from the outside world, including in the transport layer (server b, the current whereat-location-server)
feeling the need to draw!
Meitar M.
@meitar
Apr 13 2016 02:57
Oh I see what you're saying. Yeah, I was thinking that there's a need to hide it from the server operators.
In which case I don't think anything less than onion routing would work
aguestuser
@aguestuser
Apr 13 2016 02:58
yes.
so the question is, if we say we (or riseup, or someone we trust -- but crucially we have to trust the server operator) is handling the key exchange, is that acceptable for something like where@ or buoy?
Meitar M.
@meitar
Apr 13 2016 02:59
But if you can have a trusted server in the equation because your adversary is positioned on the network and not on the server…but wait then I'm not sure why splitting it into a pre-key server and a relay server would matter?
aguestuser
@aguestuser
Apr 13 2016 02:59
thus far we've been pushing really hard on "no stored state at all anywhere ever!"
but we inherit a really difficult key exchange problem as a result
^-- yeah why separate them at all is a good question.
had occured to me that way probably mostly because of scaling? but also isolation?
Meitar M.
@meitar
Apr 13 2016 03:00
I guess what I'm confused about is what your motivation for going towards a security-by-compartmentalization approach if the threat model isn't "malicious server ops."
aguestuser
@aguestuser
Apr 13 2016 03:00
in any case you've already broken the biggest security guarantee where@ has thus far been trying to make: ie -- compromising our server does (almost) nothing bad because we never put anything there
Meitar M.
@meitar
Apr 13 2016 03:02
Right, so…is your idea here that the prekeys would be handled by someone else, not Where@? The security property being: they are already defending castles, they are good at it, we are not?
aguestuser
@aguestuser
Apr 13 2016 03:02
something like that
Meitar M.
@meitar
Apr 13 2016 03:03
Yeah, that makes sense. I mean, I trust RiseUp or similar folks more than almost anyone else as far as hosted services go.
aguestuser
@aguestuser
Apr 13 2016 03:03
and that if we had to figure that out, you'd optimize the key exchange server for "really good castle defense" and the messaging server for "really awesome horizontal scaling and fault tolerance"
it's just something i've been toying with watching the impact this whole WhatsApp thing is having
thinking about access
like if you can reach 1 Billion (or whatever) people
and make them not have to even think about key exchange at all
and the cost is you have to have a keyserver...
... is that worth it?
Meitar M.
@meitar
Apr 13 2016 03:05
Well, again, I think for most people, YES. But it depends on your threat model.
Most people use WhatsApp because they're NOT concerned about being on a kill list.
If they were, they probably wouldn't even use Signal because, among other things, their clients use Google Play Services.
aguestuser
@aguestuser
Apr 13 2016 03:06
well so at this conf (i told you about it yes? the one in Spain? internet freedom festival?) it was ASTONISHING how many front line activists from the global south used whatsapp almost exclusively
because it's just so dominant
Meitar M.
@meitar
Apr 13 2016 03:06
I am all in favor for "good enough" security if the alternative is security nihilism, but as an academic question, I don't think anyone's resolved the inherent tradeoff you just pointed out.
aguestuser
@aguestuser
Apr 13 2016 03:06
particularly in countries where FB has more or less colinized the internet with FreeBasic
(people only have WhatsApp and Facebook because it's free and nothing else is)
and organizers who want to communicate with them use it
and nobody can install Signal b/c they don't have bandwidth
or they're on the free basics plan which only offers FB apps (and the phones they get have this by default)
" I don't think anyone's resolved the inherent tradeoff you just pointed out." ... yeah
:(
Meitar M.
@meitar
Apr 13 2016 03:08
Right. So if the question is "is it better that they have WhatsApp than using SMS messages?" I think the answer is obviously yes, and so in that context it's great that WhatsApp went forward with their e2e encryption plan.
aguestuser
@aguestuser
Apr 13 2016 03:08
yeah
and if that's true
and if we maybe want to reach those same folks
is thinking seriously about signal protocol a good idea?
because there are now 1 billion people to whom you can say "it's like whatsapp" and they'll actually know what you mean
thanks to the little key logo they see in the app every time they send an encrypted message
Meitar M.
@meitar
Apr 13 2016 03:10
I think Signal Protocol is going to be a Big F'in Deal because WhatsApp is using it, regardless of its actual merits. I just think Signal Protocol itself is not addressing the metadata problem beyond what TLS offers client/server comms in the first place.
aguestuser
@aguestuser
Apr 13 2016 03:10
...like i said ... toying ... not at all sure... very curious what others think!
Meitar M.
@meitar
Apr 13 2016 03:11
So I want to use it in Buoy if I can, so far I've been playing with the idea of using OpenPGP.js as a "good enough" fallback until/unless a Signal Protocol JavaScript library becomes available.
aguestuser
@aguestuser
Apr 13 2016 03:11
so if we could make a react native module that hid all the Java / Objective C stuff under the hood...
Meitar M.
@meitar
Apr 13 2016 03:11
And that's because of exactly what you pointed out: if we want to reach people today in the context of global capitalism and current tools, and the limits of our own skill set, with tools we are making, do we go for "good enough" or just say screw it, and do nothing?
aguestuser
@aguestuser
Apr 13 2016 03:12
(i know that doesn't address the desktop/browser case)
but would that help?
we do something!!!!
solidarity not nihilism! (but you already knew i'd say that. ;))
speaking of js crypto, @aepyornis has been leading the charge in figuring out the standford js crypto library. it's symmetric encryption... but we've got it working: whereat/whereat-native#25
and it was pretty simple for prototyping.
Meitar M.
@meitar
Apr 13 2016 03:14
:) Yeah, I mean, I think this comes down to a resources question for you. Can we make Where@ be A Thing if we're also building a modular messaging thing? (I have no idea how many resources you actually have, so I'm just playing sounding board here.) The reason I'm not worrying about any of the crypto modules is specifically because my answer to that question for my own projects is "No, I can't do that, too."
aguestuser
@aguestuser
Apr 13 2016 03:14
[ps: haven't merged the PR yet because we still need to adjust functional tests for the new (more generalized) crypto flow)
Meitar M.
@meitar
Apr 13 2016 03:15
This is the text box test thing! :) I was gonna look closer at that after my ES2015 catch up.
aguestuser
@aguestuser
Apr 13 2016 03:16
yeah. we had an astonishingly easy way finding our way into the library. this demo was a great help.
at any rate. probably time to scrape myself away from the keyboard for the night. very much looking forward to talking through all these trade-offs more soon!
Meitar M.
@meitar
Apr 13 2016 03:17
I just woke up about two hours ago, because Night Owl, so I'll be hanging around. Good night!
aguestuser
@aguestuser
Apr 13 2016 03:17
in particular, if it could be useful for where@ (which is now on a pretty patient timeline) to invest some time/resources in producing an interface to RN that would make it easy (b/c javascript) to use signal in buoy... that could be cool
Meitar M.
@meitar
Apr 13 2016 03:18
That would be a win for me for sure.
ziggy
@aepyornis
Apr 13 2016 15:59
wowza, i gotta read the gitter more regularly. catching up on all these .
So. Today or Tomorrow I'm going to re-write the functional tests so we can finally merge that in and move on to whatever's next.
ziggy
@aepyornis
Apr 13 2016 16:07
but yeah, https://ricochet.im/ is super cool.
chat with me here: ricochet:uhp64uwnrtzaljh7
ziggy
@aepyornis
Apr 13 2016 16:12
One issue with pgp is that it's not necessarily designed for anonymity. That is, given a pgp message you can figure out the ID of the key of the person who wrote it. This is normally fine for emails because the assumption is, if someone is spying on your email, then they already know it's you. For our current whereat model, we want people be be able to send messages that are encrypted and anonymous because everyone can read the traffic of everyone else. Someone who gets a whereat encrypted message should not be able to read it or tell who wrote it (even if that "who" is just a consistent id number).
ziggy
@aepyornis
Apr 13 2016 16:20
Also, I'm just learning this stuff. Absolutely not an expert. so @meitar and whomever, please join the crypto bandwagon!
Ricochet / tor is probably something we should examine and learn more about. Inside the tor network you get exactly that promise: encrypted and anonymous.
aguestuser
@aguestuser
Apr 13 2016 17:10
I've thought that (about Tor) quite a bit -- but it's far from "realtime'
:(
But maybe that's okay?
ziggy
@aepyornis
Apr 13 2016 19:54
I've been using orfox/orbot on my phone recently and I've been quite surprised at, given that it's tor on a phone, at how fast it is.
Meitar M.
@meitar
Apr 13 2016 22:09
@aepyornis Yeah, the only reason I'm looking at OpenPGP.js for Buoy is specifically in that project, traffic is not broadcast to all users. There are access controls on who can even ask for what messages from the server, so we just need privacy, rather than anonymity. Also, there are relatively easy to use JS libraries for it. :) But in Where@, clearly, PGP is insufficient.
As for hopping into the crypto stuff myself, I'd love to, but not sure I can until I finish @aguestuser's primer for new contributors, which is taking me a while because I'm juggling several other things. But if there's another way or path for me to take to jump into this that would also be helpful, LMK?