Encrypted messengers: Riot, not Signal, is the future(titus-stahl.de) |
Encrypted messengers: Riot, not Signal, is the future(titus-stahl.de) |
I think something worth keeping in mind is that almost everyone who works in secure messaging agrees on one thing: that electronic mail is not the future of secure communication.
There's no fundamental reason why that should be the case. The store-and-forward model used by SMTP could be made to work for asynchronous secure group messaging. You can get forward and future security with it. It can interoperate with existing email addresses. All of that can be made to work.
But it is the case. Email won't be a secure group communication system. The reason for that is that email is federated and thus permanently mired in the lowest common denominator of mainstream email clients.
I think reasonable people can disagree about whether it's tractable to create a federated secure group messaging system with what we know right now. But I do not think it's reasonable to suggest that the concern (federation = lowest common denominator security) is invalid. And that's what this piece does.
My assumption with Matrix is that if some fatal flaw is found in the Olm/Megolm E2E implementations, we'll work with the major clients/bots/etc to implement a (if necessary) incompatible fix... and fork the community. Folks stuck on old insecure conversations will be isolated and shamed into upgrading - much like insecure HTTPS algorithms get killed off by pressure from browser vendors.
Yes, this process takes longer than a centralised solution which can flip the switch serverside and then worry only about upgrading all the apps, but in exchange you get freedom, as well as some level of security.
Obviously, email is the best case in point. There's been a decade and a half of concerted effort to get some baseline level of crypto security for email, and all of it has run aground on the installed base of dumb email clients.
To believe we should be cavalier about the risk of this happening again is to assert that we know enough now not only about how to design a secure group messaging system, but also how to safely implement it, that we should freeze the current state of the art in amber by standardizing it.
Personally, I can resolve this for myself quickly. I log into my Linux server, type "man 4 random", see that we can't even properly standardize the secure way to generate a random number, and quickly conclude that I'd rather use a single system that Moxie and Trevor are actively designing and evolving than adopt the consensus protocol of a menagerie of different unrelated messaging projects.
This level of oligopoly would not be tolerable to those who want to federate Signal-like apps. The whole point is to make it practical to use a small operator that's not such an easy target for one government's intervention (eg an NSL). But that ecosystem looks much more like email than web browsing - diverse, but fragmented, and impossible to upgrade in this way.
"Riot’s encryption is not yet fully stable and, more importantly, it is not yet enabled by default in chats (you have to enable it manually). This will be changed in the future, but makes it more likely for users to make mistakes until then."
Users "make mistakes"? By using the defaults? I consider it a mistake to promote it to the users with such defaults. A "secure" product which "doesn't encrypt by default"? And "it's not stable"? What does that mean? The encryption either works or not. "Almost working" is still "not working."
Then please don't write
"An alternative to Signal is Riot." It is not. As far as I understand it just "could once be an alternative."
But based on the responses I've received here to my questions about Riot, it's promising: according to them, I will be able to set up my own network of people (e.g. just my family) with which I'd like to communicate. Yay! (thanks to mxuribe and NoGravitas for the answers)
Encryption currently works on Riot Web, iOS and Android, certain bugs excluded - but it's missing a lot of UX work. (Among other things, you have to manually verify each and every device the people you talk to use, there's no way for them to say "these are all my devices, if you trust me, you trust them" yet. You also lose chat history at present if you switch devices or log out.) If you're able to work around the UX, the underlying protocol is fine and has been audited, with certain tradeoffs discussed in the report.
I think the intention of Titus' article is to comment on where things are going in future... hence the title: "Why Riot (and not Signal) is the future".
One important benefit of email is that you're not reliant on any single provider for your communication. Slack and Signal and systems like them are provided by single companies, and the continued function of those systems depends on the companies. Your long-term happiness with those systems could be influenced by how those companies interact with foreign or domestic governments' requests for surveillance, for censorship, etc. What will happen if one of these companies is ordered by a government to, like Lavabit, backdoor their system, or defeat the encryption on a device like Apple? Perhaps it will happen through secret court order and we'll never know, or perhaps the company will decide to shut down like Lavabit - as a user both are bad options.
With email, you can host your own email server, and take the fate of your group's secure communication into your own hands. For anyone to get your data they'll need to come after your devices directly; they can't just send a court order somewhere to obtain information about your communication - not even metadata. Although systems like Signal may not have the preexisting ability to eavesdrop on the substance of your communication centrally, they may be able to eavesdrop on your metadata and contact list, and it's possible that they or any vendor involved in app distribution such as app stores, OS vendors, telecom providers, device manufacturers, could be ordered to collect your data or metadata, or even build and deploy a backdoor.
As far as security, I think email is adequately secure for private group communication for most purposes. Many of us do rely on email for just that purpose within our organizations (e.g. companies). If your organization has a central mail server that authenticates its members, then you can get to a pretty good state fairly easily. Microsoft Exchange and Active Directory are an example of this. Gmail for business. Postfix with an LDAP server.
All modern email clients communicate with mail servers over TLS and will authenticate the server, just like a browser authenticates an HTTPS website. Modern email servers authenticate the client. What important security property do we get from the alternatives that we don't get from email? End-to-end encryption is the only one that occurs to me, and in an organization where we can trust our central server that's OK not to have. I suppose this is an easier proposition for companies than for loose groups of people organizing over the Internet. If you use a hosted email provider then obviously you must trust them, but self-hosted options are available and realistic (Exchange, Postfix).
Now, granted, what I am describing is a private organization rather than a federation. What's really cool though about email is that we get secure group communication within the organization, and also federated communication to other organizations on the Internet.
The security story for communication between organizations is weak, I'll grant. The primary weak link I see is not end user clients, but the communication between servers. Specifically, the lack of support in standards and servers for authentication of receiver by the sender, and for the receiver to declare that all incoming connections should come over TLS with a path-validated certificate. There is an Internet-Draft out for this called SMTP Strict Transport Security [1], but I don't know where it stands as far as support and adoption. DMARC+DKIM already provides authentication of the sender's organization by the receiver, and for declaring that all outbound messages from the sender's organization must carry a signature to be valid.
There's a fair amount of surface area in this model though: in particular, both end users and their mail servers need to be trusted. If in your communication between two organizations, you are willing to trust both organizations' central mail servers, then basic email setups will get you to a pretty good situation.
Some colleagues have recently made the case to me that S/MIME could fill in these gaps, and mentioned that folks in the industry are working to flesh out support for it. There are a number of problems to solve to make S/MIME practical, but with the will of a few major players I think we could get there. Some pieces that are missing include first-class client support, a key exchange/discovery/revocation system, and a scalable certificate issuance system. But solving S/MIME is only necessary to get to end-to-end encryption, and for most purposes it's practical to trust your organization's and partner organizations' email servers.
Even if email is not the secure group communication of choice, it's still used for a lot of secure communication and is worth improving IMO. I'm glad that Google and other have been investing in this: https://blog.google/products/gmail/making-email-safer-for-yo...
That is the problem at hand, that Signal _does_not_federate_. You could modify your Signal app to connect to your own server, but then you would not be able to talk to anybody else.
For the record I prefer usability and walled-garden-security instead of federation, even though it hurts to admit as a long time FOSS user.
However I see no reason why a similar p2p app couldn't manage similar without a central server. Trick is cell phones (at least on WAN) do not accept incoming connection. Additionally apple/android push aren't good for a p2p transport.
However adding supernodes (like the original skype) that could run on raspberry pi's, opensource routers, and similar embedded devices might just bright the gap. After all the cpu, bandwidth, and memory needs for instant messaging are pretty modest, even for many people sharing a raspberry pi.
You can, right now, run your own server and get other people to also run their own servers. Fork the Signal app, modify to ask for a server to use, and try and get people to use it instead of (or as well as) Signal itself.
I'm not part of the Matrix or Riot teams, but I'm convinced enough that Matrix is a great way forward for modern messaging. I started my own Matrix homeserver (as well as other Matrix libraries, eventually to include a Matrix client) written in Rust. If you're interested in Matrix, Rust, or both, I encourage you to get involved! https://www.ruma.io/
[1] https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-en...
Still, this is only one piece of the overall security of Riot, so I'm still interested in knowing if there's any work going on looking at the bigger picture.
You can run your own private Signal service with OpenWhisperSystems' tools [1].
It's also worth noting that Signal - as a protocol - could easily be federated. (As others have mentioned, Moxie has chimed in on why the app is centralized [2]).
If confederated messaging is important, why not use the existing Signal protocol implementations, (including the X3DH key exchange, ratcheting protocol, etc), which is all F/LOSS, and has already been widely reviewed (as the article mentions)?
[1] https://github.com/WhisperSystems/libsignal-service-java
[2] https://whispersystems.org/blog/the-ecosystem-is-moving/
A distinction without a difference. I use Signal because people use Signal. People do not use 'the Signal service'. They use OWS's app and OWS's servers and moxie has explained he will not federate.
The fact that OWS goes to all the effort of creating this excellent protocol, and then insists on only deploying it to insecure devices (with direct-memory-access baseband radios) baffles me, but I hope that things move in a saner direction with time.
The biggest benefit I think OWS has provided is the ability for other platforms (e.g. Whatsapp) to use their protocols. I daydream about a day when all these competing messaging services realize they would stand to gain a lot by federating, but I know it won't happen in my lifetime.
1. How well does Riot deal with changing network connections? Does it have problems when a mobile device switches between, say, WiFi and 4G? How well does it deal with a complete loss of connectivity?
2. How well does Riot deal with power management on mobile devices? Can it spend time in the background while getting message alerts while not running down the battery?
I actually came to matrix after trying to write an XMPP client, believe it or not. The matrix protocol is WAY better equipped for the future than XMPP is: it simply has the core designs necessary to make it federate well and do message sync without losses. (XMPP doesn't. (Unless you count a half-dozen XEPs, none of which are reliably implemented in all clients. But we're getting increasingly parenthetical here; by comparison, matrix Just Works.))
* https://matrix.org/docs/guides/faq.html#i-installed-riot-via...
>I installed Riot via F-Droid, why is it draining my battery?
>The F-Droid release of Riot does not use Google Cloud Messaging. This allows users that do not have or want Google Services installed to use Riot.
>The drawback is that Riot has to pull for new messages, which can drain your battery. To counter this, you can change the delay between polls in the settings. Higher delay means better battery life (but may delay receiving messages). You can also disable the background sync entirely (which means that you won’t get any notifications at all).
>If you don’t mind using Google Services, you might be better off installing the Google Play store version.
Can anyone justify why they are necessary?
http://stackoverflow.com/questions/6578051/what-is-an-intent...
Edit: Reading your link now, as I didn't see it before I made my comment. Was that added in as an edit?
https://support.whispersystems.org/hc/en-us/articles/2125358...
> In addition, people are writing alternative clients to access the Matrix/Riot network, implementing their favorite features and workflows. As users can vote with their feet for their own interests and choose providers and apps of their liking
Can I run my own network which is not part of other networks (i.e. not "federated")? Can I tell somebody "call with your Riot client 'acqq at server ip nnnnnn' and we can talk"?
1. You and your friend both use the riot (actually matrix.org) server/network and you both choose any matrix-relevant client (doesn't even have to be the riot client), but only make use of private rooms on that server. This avoids any system setup overhead whatsoever...But the private room(s) that you create would still on a server that is not controlled by you.
2. You can of course setup and run your own little private network; on your own domain name/IP address. This is what I do with my family; and only my wife, and daughter have access (I've even disabled registration). I have not yet connected my little network to the greater matrix network...For 2 reasons: I wanted to beta test this internally so I could leearn; Also, i wanted to be sure my family does not get exposed to any spam (if there is any that is).
Good luck; cheers!
Also, how puringpanda's question fits to your claim?
In both cases you can start chatting with any signal user in your address book in a minute or so, no expertise (other than using an app store) needed.
Tracked down the http://riot.im, it has a "try now button", that just scrolls you to the top. Didn't see any way to actually try it.
I tried the ubuntu app, they make you manually create your own /etc/apt/sources.list.d, from only the base URL. Then you have to know how to add the pgp key. Then apt-get update, apt-get install riot-web. Then... nothing. Nothing called riot or riot-web in the path. Thought maybe there would be a daemon running (it's called riot-web afterall). Can't find any processes running, nothing listening on a new socket. I track down /var/lib/dpkg/info/riot-web.list, look through the list and find they dropped a dir in /opt. So I run /opt/Riot/riot-web.
It worked, not exactly the kind of thing I'd ask random friends/family/colleagues to do though.
In the meantime, it's not like you can migrate your Signal, Telegram, iMessage, or even Gmail/Hotmail accounts. I think Matrix needs a few more client/server implementations before the spec can't truly be set in stone.
MSISDN (phone number) identifiers landed on the backend this afternoon; implementation in the Riot clients will be coming very shortly.
There are broadly two ways of solving it:
1. have a naive implementation where users can configure their accounts to replicate between sets of servers, and clients have primary and fallback servers they can talk to if the primary isn't available.
2. switch to a p2p model where each device has its own server, and so account data is automatically replicated across multiple devices. This has a host of other advantages too (e.g. you can own your data without running your own server; you can adopt metadata-protecting federation transports; you can still use all the existing apps today as the client-server API remains the same; you can still bridge with the Matrix network of today).
#2 is obviously way more work, and is effectively rewriting the federation side of Matrix. However, Matrix is designed to evolve and we're not ruling this out from happening at some point. Meanwhile #1 is more likely to land in the nearer future. We haven't got it scheduled in yet, but it's very much on our minds!
I just hope matrix ends up working better than xmpp.
EDIT: Thank you for the responses! It pretty much confirms what I thought; Apple _could_ access your communication (either through keylogging at the OS level or backdooring Signal) but this solution is better than everyone use plain text communication. I personally would not trust Apple with my life if I needed that level of protection but maybe that's not the main use case for Signal.
"According to Galen, any books found on ships that came into port were taken to the library, and were listed as 'books of the ships'. Official scribes then copied these writings; the originals were kept in the library, and the copies delivered to the owners."
https://en.wikipedia.org/wiki/Library_of_Alexandria
Sounds like Napster, yes? Think about how much harder it would be for Congress to pass laws shutting down the digital equivalent to a library sharing the world's music.
But no. We get names like Riot, and Felony (https://github.com/henryboldi/felony). Congress sends you a "Thank you" every time you put an edgy name on something disruptive.
Is this correct? I've never bothered looking it up, but Signal was connecting me with people in my phone's address-book.
On Matrix/Riot, userids are federated in the same way as emails. So when you change providers, your userid changes, but your contacts' stay the same, and you can still connect with them from your new provider.
Anything else is either much less secure, or much harder to install/use.
Matrix is a generalized protocol for decentralized and federated communications; it's agnostic to the application layer provided by Riot. Something Matrix doesn't have, but is on the issue backlog, is support for email-esque thread contexts. [0]
Care to share what you mean by PGP leaks a lot of metadata? You might be right, I'm just not aware of such details.
Whatsapp has already backtracked on some major privacy promises, and who's to say it won't backtrack on the end-to-end encryption support eventually, after everyone is baited and switched to it? Or worse, it could start to decrypt E2E communications in secret for governments.
So we need a "mainstream" alternative that's actually trustworthy and can at least protect the security of the communications, if not the relationships between users.
However, I support applications that aim to offer even better privacy and security compared to Signal, that are aimed at more opsec-sensitive targets, such as journalists. Signal may be the best tool journalists have right now, but it's probably not the best one they could have, as it doesn't do a great job at protecting sources. Perhaps Ricochet or the Tor Messenger may be better for that.
What I'm worried about though is that even if these apps offer better security/privacy features, the various federated applications that use an E2EE protocol may not have too much of a security mindset. For instance, sure, Riot may adopt a better protocol, but is Riot itself using all modern security best practices? Can we trust the Riot developers just as much as we do the OWS developers? etc
Finally, I'd much rather see Signal become a P2P application than a federated one, if that would even be possible.
Originally skype did this, skype users with a good network connection, good uptime, and who accepted incoming connections could self promote themselves to a supernode. This allowed async messaging for others, helped introduce peers who couldn't talk directly because of IP Masq/NAT etc.
So it's possible that signal could write a small application that could be a supernode. Ideally it could run on a Raspberry Pi, Plug computer, or even any of the numerous opensource routers. What way your battery sensitive phone wouldn't get run down by participating in a DHT or similar, but your raspberry pi could act like your inbox and facilitate incoming and outgoing messages.
We have to trust someone, eventually. This is especially true for the 99% of the population who doesn't have the skill to compile source themselves (nor should they have to).
http://wiki.c2.com/?TheKenThompsonHack
Ken describes how he injected a virus into a compiler. Not only did his compiler know it was compiling the login function and inject a backdoor, but it also knew when it was compiling itself and injected the backdoor generator into the compiler it was creating. The source code for the compiler thereafter contains no evidence of either virus.
That's the exact reason why package signing is decentralized in the Android ecosystem. All apps in the Play Store are signed by their developers.
Similar questions include: What if a CA is compromised? What if Apple/MS bundles unwanted certs with the OS? What if Intel/AMD biases the on-die hardware RNG or other hardware crypto primitives? What if Apple/MS bundles a backdoored compiler a la "Reflections on Trusting Trust"? What if MS/Apple backdoor the entire network stack, including the physical and data link layers? etc. etc.
Which is to say, security-minded users should strive to trust as few parties as possible, but since at the end of the day you have to trust somebody if you don't trust Apple the only really secure move would be to not use iOS devices at all.
But if the user has another OS, then you can believe those who get control of that OS/device can read your messages to that user and record your calls to him/her.
It's turtles all the way around. The more communication the less can you expect to remain "private." Come to think, it is so without computers too.
These aren't high priority problems right now for mass surveillance, as we have people using plain text chat. If you're expecting a wealthy adversary to directly target you, then the only safe move is to avoid technology.
Unless every single part of your platform is open and you build it yourself. But then make sure the parts you use to build it aren't tampered with.
I think somewhere along the conclusion of that train of thought you'll need to build a fab to make sure there aren't silicon level backdoors in your hardware.
However, I don't think that decentralised solutions have to end up in the worst-case scenario we see with SMTP (or even random(4)), or the medium-case nightmare of (say) phasing out SHA-1 TLS certs. There's a spectrum of nightmare here, and you can engineer both the tech and the governance to enforce a culture of security awareness and aggressive upgrading until things move fast enough. In practice, this means:
* Set a cultural precedent that obsolete clients are a bug, not a feature, and should be killed off or upgraded.
* Ensure that the most popular clients are actively supported to implement security features. If necessary, the standards body itself should get off its ass to do the work in order to protect the integrity of the ecosystem.
* Set a cultural norm of shaming users and developers who don't upgrade for security features - the same societal pressure that generally stops people wandering around in public if they're covered with chickenpox.
* Enforce it in the largest public communities of the ecosystem - in Matrix, this would be #matrix:matrix.org and a bunch of other huge >5000 user rooms, where if one day we had to make an incompatible protocol change, it'd suddenly be abundantly clear that folks on old clients would be excommunicated until they upgraded. We believe that users would rapidly find a way to switch client or encourage their developers to upgrade if it meant they were no longer able to participate in the biggest rooms!
* It's obvious, but: layer the protocol so that functions can be swapped out easily, just as Matrix allows arbitrary future E2E protocols in addition to today's m.megolm.v1.aes-sha2.
SMTP's woes stem from innocently trying for backwards-compatibility at all costs; not layering the protocol; having no governance model or culture which shamed ancient or obnoxious MUAs into being abandoned or fixed.
Slowness of SHA-1 phase-out in HTTPS is more the community again being conservative about backwards-compatibility, and a rather cautious attitude from the browser vendors in deploying the upgrade due to fear of upsetting everyone's expectations that The Web Never Breaks. Again, if you had more of a willing attitude that sometimes there's a security disaster and everyone has to upgrade (assuming that the software mechanisms are in place to upgrade and you haven't baked into hardware etc), perhaps people would be more willing to move faster.
So, with Matrix, we're trying to instil that attitude from the outset, whilst ensuring that the tech can support it. Time will tell whether it will work :) Better worth trying than to give up on federation and decentralisation entirely, though: privacy has no value without freedom.
If I understand puringpanda's question, the idea is that your domain and your homeserver are seized, but you have contacts on other homeservers. At this point, it's just like losing your email server. You lose your existing ID, and probably your message history, but you can reach your contacts from a new ID you create someplace else.
If the threat model for the communication within your group is concerned with attack or coercion from hostile governments, then you have the ability to set up your own email server and convince your participants to switch to it. It's not really much to ask -- it's fairly routine for companies and organizations to issue email accounts to employees/members and require their use for official business.
Consider that it may be easier to ask your communication partners to start using a new email account you've provided them than to adopt a new communication platform.
On the other hand, the people you're communicating with have chosen to trust the organizations that they're using to provide them with those services. Whatever service they're using is not radically different to trust than it is to trust the Signal developers, or the Google Play Store or Apple App Store to distribute the Signal application to your mobile device, and so on. Even if your participants are using Signal to communicate, they may have online backups enabled with their device to Apple, Google, etc., such that without your awareness your communication partners are trusting them just as much as if they were email providers.
I surely don't have a problem with the manual verification.
Can it be claimed if
- the user has to log in with his phone number to Signal servers in order to communicate
- no user can use any other but Signal servers, which are hardcoded in the apps?
It seems that it's perfectly designed to at least collect the metadata and the owners of it don't want to let you change these rules.
Google Play Services is not the standard Android platform. AOSP is the standard Android platform.
and then the long, storied history of American strike-breaking &c.
Or the threat is a government, then Signal is not secure enough either, because the US govt can just force Google and OWS to ship modified APKs.
Were this my argument, rather than pointing me to a thread where my points were continually and reliably refuted, I'd take this opportunity to instead restate my argument clearly.
With signal this is much harder, for instance google/apple do not know who you are chatting to. They also don't handle the encrypted message transport/delivery.
OWS received a Grand jury subpoena and was only able to produce "the only information we can produce in response to a request like this is the date and time a user registered with Signal and the last date of a user's connectivity to the Signal service.".
Certainly a NSL might compel OWS to add additional logging (and not talk about it). With that they could tell who messaged who, when the message was sent, and how big the message was.
NSLs cannot be used for that. They're a legal tool that can be used to extract certain types of information (such as subscriber information and maybe a little bit of transactional information) that a service provider already has stored on their servers [0]. However, they cannot be used to force a service provider to write and deploy code.
[0] NSLs are not magic - https://www.youtube.com/watch?v=YN_qVqgRlx4&t=20m16s
Anything that does TLS to connect to a single server can do that. Heck, if you do email to a single email server using secure IMAP and secure SMTP then PGP no longer leaks metadata.
Link please
Email never had this, and it shows. SHA-1 in HTTPS is a kinda intermediary example; browser and server vendors have been petrified to break legacy systems and generally not accorded that much priority to security updates. In Matrix, we hope to avoid this by setting a precedent that if Olm/Megolm is found broken tomorrow, we'd work with the major client authors to upgrade them, patching their clients ourselves if we have to, or providing a localhost shim or whatever, and then take the biggest community anchor points (e.g. #matrix:matrix.org) and throw the switch to the new protocol, and make it abundantly clear that folks on old clients have been left out in the cold for security reasons and need to get upgraded immediately. If you're a big enterprise with a private deployment who doesn't want to upgrade rapidly, that's fine. But the societal pressure will enormously be to get with the program and upgrade. Let's see how well that works though - we haven't really had to make any backwards incompatible changes yet since we started in Sep 2014.
(p.s. hi! :D)
Clients can then warn when they're in rooms with older versions than the latest supported, and since nobody wants the people they're talking to to receive scary warnings about insecurity, they'll upgrade.
And, of course, we can do similar with client versioning.
https://developer.android.com/training/contacts-provider/mod...
https://developer.android.com/guide/topics/providers/calenda...
and so on and so forth for almost any permission the Signal app needs on Android.
What if I never want to share my location, take pictures, or send files?
And then some things, like calendar access, aren't even used right now.
Don't use these features and / or disable the corresponding permissions.
This provides more choice, and reduces the amount of needed permissions.
If I'm about to take a picture for the first time using it then I'll understand it asking for camera access.
edit: "private group" can encompass a lot, especially in other ecosystems like Google and FB. If said "private group" adversary is, say, a prominent and wealthy Silicon Valley businessman and enterprising vampire who collaborates with fascists, then you can see the potential of compromising someone's security by coercing Google or Facebook engineers to run you a Hadoop query or conditionally inject malicious JS.
Except, I’d have to modify the code, as the current version depends on Google’s proprietary libs, which I can’t inspect. And I lose half of the functionality, as RedPhone is also proprietary.
> by coercing Google or Facebook engineers to run you a Hadoop query or conditionally inject malicious JS.
The same can be done by coercing OWS engineers to backdoor their services.
And in any case, Signal can start collecting metadata any minute now, and there’s nothing we could do against it.
The source code for the Redphone client is here: https://github.com/WhisperSystems/Signal-Android/tree/master...
The source code the redphone-audio library is here: https://github.com/WhisperSystems/Signal-Android/tree/master...
Stop spreading misinformation.
Moxie is simply wrong on many of these points, and has been for a while and has had this repeatedly pointed out with no change in opinion. I would rehash this here but you'd be better off simply reading the linked thread and looking at other rebuttals. In particular I remember a 500+ comment GitHub thread on the Play Services issue where Moxie was repeatedly dismissive and rude to those who take issue with the glaring security problems in Signal.
First, that's why people like Signal: it just works (TM) encryption with no user gotchas.
Second, any communication is only as encrypted / safe as the minimum of the people with access to it. So if someone ignores warnings and enters that chatroom, he or she puts everyone at risk. Because sometimes she/he really is being MITM or surveilled by someone/oppressive government du jour.
I can not build Signal from source today.
Signal still has to be linked with a proprietary binary, which contains lots of tracking code.
[0] NSLs are not magic - https://www.youtube.com/watch?v=YN_qVqgRlx4&t=20m16s
3rd parties can download the signal source and compile it. Not sure if there's enough information available to product a bit identical (and thus verifiable binary).
I guess a NSL might compel OWS to push a binary specifically for a targetted user. If that's in your threat model you definitely need to take additional steps.
To my (admittedly fairly limited) knowledge, that's something the courts have yet to rule on. They can definitely ask to you give them any data they store about their users (and force you to keep quiet about it), but whether they could force you to develop a backdoor (and ship it to someone) remains to be seen. That's basically what the FBI vs. Apple case was about, which the FBI sadly pulled before courts got to rule on it.
https://developer.android.com/studio/publish/app-signing.htm...
If you want to install an update that was signed with a different private key, the app would need to be uninstalled first, which would also delete any sensitive data in private app storage.
This is enforced at the platform framework level, from what I loosely remember of scanning the AOSP source code.
Yes, Google could hijack packages sent to first-time downloaders. That's usually the downside with trust on first use. If the initial download isn't trustworthy, the whole verification scheme falls apart. It would be better off if Android had the APK equivalent of Certificate Transparency. That, and if Google Play made all developer-uploaded APK builds available to users, for awareness.
Android is pretty open about letting you sideload and run binaries, which you can do easily as a non-rooted end user. You can personally GitHub pull & compile the Signal app and you're good to go (w/r/t compromised software download).
