Use Signal for secure text, voice, and video

tl;dr: Use Signal and encourage everyone you know to use it with you.

For years, privacy advocates and computer security experts warned the world that it would be easy for governments to spy on everything we do online. In 2013, Edward Snowden revealed that the governments of the USA, UK, Canada, Australia, and New Zealand were indeed eavesdropping on Internet traffic on a massive scale .  But at that time, it was difficult to encrypt electronic communications so they could not be spied on while retaining the features and convenience we have come to expect from technology. Now, it is finally possible with a free software app called Signal, just in time for the Trump era.  Signal makes cutting edge end-to-end encryption easy, so only the person you want to read your message can read it–not your Internet Service Provider, the Signal server operators, the US government, or anyone else. Even if you don’t think you have anything to say that they would care about, we should all have something to hide. Signal provides one-to-one and group text messaging, plus one-to-one voice and video calls. In this post, I’ll explain why Signal is the best option for encrypted communication.

Signal is the most prominent and widely used free encrypted communications program. If you’re not using it already, you may be pleasantly surprised to find some of your friends are already using it. It has a very strong focus on making the user experience so simple and straightforward that you do not have to know anything about encryption to communicate securely. Signal seems to have been the first to overcome the technical challenges of delivering encrypted messages reliably to mobile smartphones running either Android or iOS through flaky network connections in a battery efficient way. Most of the competitors are now using techniques Signal developed, which I think is a testament to the genius of its developers.

One of the essential aspects of Signal that makes its user experience so easy is that users are identified by their phone number. A registration with the Signal server is required, but there are no options regarding how to register or what server to register with, making the setup process self-explanatory. Additionally, identifying users by phone number allows the app to hook into the phone’s contacts list to make it very easy to find other Signal users.

The downside, of course, is that getting set up with Signal requires a functioning Android or iOS smartphone with cell service that can receive the initial verification SMS. It also makes using Signal with multiple SIM cards clunky. There is a desktop client, but it requires registering an Android or iOS device first. Support for registering with an alternative identifier, such as an email address, is on the development roadmap, but considering it has been on the roadmap since 2014, it does not seem to be a high priority.

On Android, Signal can replace the default SMS/MMS app to handle both secure Signal messages and calls plus regular SMS/MMS. At first, I was skeptical about this. I thought it was a bad idea because it would be too easy for users to get confused between sending insecure SMS and encrypted Signal messages. However, now that I have used it, I am very impressed with how straightforward it is to distinguish between them. I am also amazed at how convenient this is. There is no need to use two separate apps, one for secure communication and one for insecure communication. There is no need to remember which contacts are available in each and remember to use the secure method when it’s available.

Additionally, using Signal for insecure SMS serves as a great way to grow the Signal network. Signal displays a notice encouraging the user to invite their contact to Signal when communicating via SMS for the first time through the app. Unfortunately, this feature is not available on iOS because Apple does not provide a way for third party apps to replace the stock iMessage app. However, when an iOS user messages a Signal Android user through plain SMS, if the Android user has Signal configured to send SMS, the Android user’s reply will be sent through Signal and the iOS user will receive it in Signal, reminding the iOS user to use Signal without any thought by either user. This is a big advantage for getting people to consistently use a new app.

Listening ahead

As one of the first secure communication apps for smartphones and with its extraordinarily well designed user experience, Signal already has millions of downloads on the Google Play Store (Apple does not publish the number of downloads for apps in the iOS App Store).

Signal has already shown resilience to attempts to block it. Egypt and the United Arab Emirates  tried to block access to Signal, but  Open Whisper Systems, the developers of Signal, fixed that within a few days. OWS has received a subpoena for user data in the USA and successfully fought it.

OWS is a small nonprofit organization, but they have demonstrated a very strong commitment to making secure communication accessible to the masses. I do not think OWS will stop improving Signal, operating the service, or be shut down any time soon. Thus, I use Signal, and I recommend you do too.

The long winding road to software freedom

Signal was started at the beginning of the smartphone era in 2010 by a startup called Whisper Systems as two separate programs. These apps, TextSecure for encrypted SMS and RedPhone for voice calls, were only for Android. They were originally proprietary software, then released as free software when Whisper Systems was acquired by Twitter in 2011. Because Apple does not allow third party apps to programmatically send or receive SMS on iOS, the original TextSecure was unable to be ported to iOS.

One of the founders of Whisper Systems, a curious character who goes by Moxie Marlinspike, quit his corporate role at Twitter in 2013 after a near-death experience while sailing. He revived Whisper Systems as a nonprofit called Open Whisper Systems, funded by the USA federal government’s Open Technology Fund (at least at first, I do not know if they are still funding OWS) and anonymous donors. OWS hired several developers and designers to resume development of TextSecure and RedPhone as free software. The now-discontinued CyanogenMod Android ROM integrated the TextSecure protocol into its SMS handling and used its own server federated with OWS’ server. A second version of the TextSecure protocol was developed using the phone’s data channel instead of SMS, allowing it to be ported to iOS. Shortly thereafter, TextSecure and RedPhone were unified and rebranded as Signal.

For several years, Signal was not so great in terms of software freedom and had a rough relationship with the wider free software community. The server software was published as free software under the Affero GPL for the TextSecure protocol, but the RedPhone server remained proprietary. OWS has not stated why the RedPhone server remains proprietary. My guess is that it started from some proprietary software that the original Whisper Systems (before Open Whisper Systems) acquired a license to use but does not have the legal authority to relicense. Worse, the Android client depended on the proprietary Google Play Services for battery efficient push notifications through Google Cloud Messaging. Furthermore, Moxie would only distribute the Android client through the proprietary Google Play Store app, citing a variety of logistical and security concerns.

A fork called LibreSignal using WebSockets instead of Google Cloud Messaging for push notifications was developed, but Moxie did not allow it to connect to or federate with the OWS Signal server for a variety of reasons. So, LibreSignal users would be able to communicate with other LibreSignal users,  but not people using OWS’ Signal app, making it not very useful. LibreSignal could only handle text messaging, not voice calls, because the RedPhone server was proprietary. Also, the federation with CyanogenMod turned out to be a major drain on OWS’ limited labor resources and ability to innovate with the protocol. So, Moxie chose to prioritize Signal’s consistent user experience and OWS’ efforts on developing Signal as more important than software freedom.

A number of pull requests were submitted to support using WebSockets for push notifications in upstream Signal and remove the dependency on proprietary Google Play Services, but they were rejected for technical shortcomings. Furthermore, they could not support voice calls because the RedPhone server software remained proprietary.

In early 2017, Signal added support for voice and video calls using WebRTC and simultaneously implemented WebSocket push notifications, finally allowing all core Signal functionality to work without proprietary dependencies. As of February 2017, Signal still requires proprietary Google Maps to send a location to another user, but users without Google Maps can open location messages from other users in an alternative map app such as OsmAnd.

There are still outstanding issues preventing OWS from distributing Signal outside the proprietary Google Play Store, but builds are available from an unofficial FDroid repository. This build is rebranded as LibreSignal, but it is not the discontinued fork mentioned above; it is built from the same source code as Signal in the Google Play Store. If you do not trust that FDroid repository, you can now build Signal yourself and run it without proprietary dependencies.

making an EFI & BIOS x86 universally bootable USB drive

To make Crossfade GNU/Linux, I set out to make USB drives that have:

  • a bootable operating system that could run on any computer with an x86 CPU
  • persistent storage to save setting across reboots
  • the rest of the space on the USB drive available to store music that looks like a normal USB drive with a single partition to Windows, Mac OS X, GNU/Linux desktop environments, and Pioneer CDJs

Macs have EFI firmware, and although they have a BIOS booting compatibility layer, that compatibility layer does not have a USB driver. So, it has to be EFI bootable, or it would be worthless to a lot of people. EFI firmware reads GPT partition tables, so I thought it had to have a GPT partition table.

Considering that CDJs only read the first MBR partition (and Windows XP and older do not support GPT), it needs an MBR partition table. So, to make it work with both MBR and GPT, I read every bit of information on the web I could find about hybrid MBR partition tables.

I realized that the computers in UIC’s library would let me boot from a USB drive even though the machines in the first computer lab I tried would not. So, instead of studying neuroscience or music, I spent much of my evenings after class my senior year of college hopping back and forth between Windows and Mac computers in the library with a few USB drives, booting into GNU/Linux from them to use GNU/Linux programs to set up another USB drive. After about two weeks of guessing and checking, I finally figured out how to make it all work.

At first, I used a hybrid MBR partition table. Ironically, by figuring out how to set up the hybrid MBR, I figured out that a hybrid MBR was not necessary.

For a while, my attempts to set up a hybrid MBR so that the USB drive could boot on Macs were not working. I could not have a type EE partition first in the MBR. Type EE MBR partitions normally signal to read the GPT partition table and are typically the first partition in a hybrid MBR, with up to 3 partitions after that in the MBR table. However, putting anything other than the music partition first in the MBR would cause CDJs and Windows to not recognize the music partition. I played around with including different GPT partitions in the hybrid MBR and putting partitions in different orders in the MBR and GPT tables. After a lot of trial and error, I realized that the Mac EFI implementation was not reading the GPT partition table at all when there was not a type EE partition first in the MBR partition table.

Could I make Macs EFI boot from an MBR partition table? I tried putting the EFI System Partition with GRUB installed on it in the hybrid MBR partition table, without the type EE partition first. To my surprise, that worked. Non-Mac x86 computers could still boot it, either by BIOS booting the version of GRUB installed in the MBR or EFI booting the version of GRUB installed to the EFI System Partition.

The GPT partition layout I came up with is:

  1. GRUB BIOS partition, partition type ef02
  2. EFI System Partition, FAT32, partition type ef00
  3. OS root, ext4, partition type 8300
  4. /home, ext4, partition type 8300
  5. music up to 2 TiB boundary, FAT32, partition type a700
  6. music beyond 2 TiB boundary, HFS+, partition type af00

The hybrid MBR table contains:

  1. GPT partition 5 (music), partition type 0c
  2. GPT partition 2 (EFI System Partition), partition type ef
  3. protective MBR partition, type ee

But wait, if Macs can EFI boot from a USB drive with the EFI System Partition in the hybrid MBR, does there even need to be a GPT partition table? It turns out that no, there does not need to be a GPT partition table and a messy hybrid MBR. The missing piece of the puzzle that I did not find anywhere on the web is that Macs’ firmware will EFI boot a USB drive with an EFI System Partition in an MBR table, as long as there is not a type EE partition first in the MBR table. Perhaps this is an unintentional featurebug that Apple never anticipated, but it makes Crossfade possible.

The simpler MBR partition table is:

(1 MB post-MBR gap)

  1. music partition, FAT32, partition type 0c
  2. EFI System Partition, FAT32, partition type ef
  3. OS root partition, ext4, partition type 83
  4. /home partition, ext4, partition type 83

So, I made the Crossfade GNU/Linux installation script install the BIOS version of GRUB to the master boot record of the USB drive and install the EFI version of GRUB to the EFI System Partition in the above layout. It still sets up a GPT partition table with a hybrid MBR if it detects that the drive is larger than the maximum size that MBR supports (2 TiB).

If you want to set up a single USB drive so it can boot on Macs and non-Mac x86 PCs, plug it into a computer running GNU/Linux. Do not mount the drive. Create an MBR partition table on the USB drive. Create a partition in it with typecode ef for the EFI System Partition. Format that partition vfat/FAT32 and mount it somewhere. To install GRUB, run:

grub-install --target=i386-pc --boot-directory=/EFI-System-Partition-mount-point /dev/USB-DRIVE #The whole drive, such as /dev/sdb, not a partition on it
grub-install --target=x86_64-efi --boot-directory=/EFI-System-Partition-mount-point --efi-directory=/EFI-System-Partition-mount-point --removable

On Fedora, and likely CentOS and RHEL, replace grub-install with grub2-install.

If you are installing a 32 bit OS and want to make it bootable on the first x86 Macs with 32 bit EFI firmware, you can install the 32 bit version of EFI GRUB to the EFI System Partition too.

Create a grub.cfg file in the grub directory (or grub2, if you use Fedora) on the EFI System Partition to boot your live OS, unmount any partitions of the drive you have mounted, and there you go!

I have been focusing on contributing to Mixxx since I published Crossfade 0.90, but I do intend to update it at some point, perhaps after Mixxx 2.1 is released.