Like I said it's not about the average person, it's about someone with something to hide. Those with something to hide will always go the extra distance.
The issue I take with the FBI approach is it will have no effect on those that have stuff to hide but destroy any semblance privacy for those that don't.
Terrorists will use GPG, citizens will use their backdoored iPhone full disk encryption and everyone but the terrorists lose.
> it's not about the average person, it's about someone with something to hide
Keep in mind that the FBI would love it if everyone held that to be true. We all have something to hide, average person or not. No matter if you are a criminal, political activist, pervert, lawyer, priest, or just the baker down the street. Paraphrasing John Oliver: your banking statements, medical data, dick pics, private messages, dick pics, dick pics, and your secret diary are all things you most likely want to hide.
The FBI would not mind a situation where only people with technological know-how use GnuPG, LUKS with dm-crypt, etc., and the rest whatever came with their smartphone. Most criminals are not particularly tech-savvy, so if that group loses access to strong encryption by default, they largely gain what they want.
Of course there is no practical way to make the use of strong encryption by individual citizens around the globe illegal, and they know this. They may however succeed in outlawing strong disk encryption available by default on store-bought devices. So when a suspect uses an Android or IPhone, and the FBI has his or her device, they want to be able to access its contents without the suspect's consent. Ideally, they also want the most popular messaging platforms (like Facebook's WhatsApp) to have a backdoor available, in order for the vendor to be able to comply with warrants for such data.
That's a problem too. Right now people with something to hide don't stand out amidst a background of similar encryption. If they suddenly have to switch to something relatively more exotic, that alone would be a coup for people in signals intelligence, don't you think?
Yeah definitely. This is currently the problem with ToR.
The people that need the protection that ToR provides paint a target on their backs because there isn't enough ToR usage for them to be inconspicuous. Which is sad.. because for all of the bad usage of ToR there are people that depend on it to preserve free speech and any weakening of it could easily get them imprisoned or in many cases executed.
It doesn't have to look "exotic" at all: Sam just sends Joe a file in base 64. But that is how all the multimedia content is sent in e-mail now. Until dig into what Sam sent, it looks like just another JPG file sent in e-mail. But translate it from base 64 and give it to an image program and will discover that the file is not a JPG file. Or a PNG, BMP, MP3, WAV, EXE etc. file either. But about have to translate from base 64 to conclude this.
Would it be possible to provide crypto as an open source "interface library" to commercial applications? So instead of the application doing the crypto (eg. Apple iOS) it would be farmed out to an optional library of the user's choosing.
Apple could make it easy for a user to install such a library and then say (truthfully) that the cryptographic functions of their OS is not in their hands, since that feature is handled by a third party open source maintainer.
At that point it would be an infinite game of whack-a-mole for the FBI to try to get backdoors in open source crypto interface libraries which could be maintained outside of the US.
A whack-a-mole game the FBI has no chance of winning.
How? Keep the de/encryption software simple, dirt simple, just open source C code, run as a command line program on, say, an old PC/DOS system with no hard disk. For encryption, just put the file on, say, a smartphone, to be encrypted on a diskette, give the diskette to the PC, erase the orignal file from the smartphone, have the command line C code on the PC do the encryption and write the results as a base 64 file to a diskette, and, with no effort at all at encryption or security, let the smartphone read the diskette and send the file. Simple.
Just keep it simple, just dirt simple, really small, open source code.
The de/encryption has to be, what, just a few loops in C, in a few hundred lines of code? The rest is just dirt simple C file I/O just one byte at a time? So, very much do not want some 100,000 line app with the de/encryption buried deep inside somewhere. And want the de/encryption run on some other device, maybe an old PC/DOS machine with no hard disk and no network connection. Or get a Raspberry Pi running some simple operating system and where can be sure that no important data will be left on the computer.
