Never outsource security if you actually want security...
Sometimes when I'm wearing my tinfoil hat I wonder if the advice to avoid rolling your own crypto is a conspiracy. The powers that be want to maintain their backdoors, maybe? Probably not. Of course, it's definitely true that there are more attack vectors out there than an amateur can be aware of.
I think I remember a scifi story that mentioned some character who worked in the one-time-pad shipping business. I guess a spacecraft full of data storage can hold enough random data to last for a long time.
Seems like we should at least come up with a proper protocol for it, so we can at least get started with something that's broadly compatible.
…you're not using a one-time pad. OTP requires the pad to be truly random: at least one bit of unique, never-used-elsewhere entropy for every bit in the message. Merely XORing some plaintext with a pseudo-random stream based on a smaller seed, which as you say is the basis for various other encryption algorithms, is not a one-time pad.
The real problem with OTP is key distribution: You need to share pads with everyone you might want to communicate with, one pad per sender/receiver pair, and those pads need to be at least as large as all the message you'll eventually want to exchange. There is no OTP equivalent to public-key cryptography where you only need one private/public keypair per recipient.
I wouldn't call OTP "fragile" or "hard to use", but you're correct about the key distribution difficulties.
Unless that was a preshared key, you're not talking about a one time pad. One time pads are inherently symmetric. If you're comparing symmetric to assymmetric crypto systems, you might as well just say that 'if my grandmother had wheels, she'd be a bicycle'.
Stream ciphers and OTPs are both symmetric.
The "symmetric" part is the fact that the same key is used for encryption and decryption, not that the plaintext and key are the same length.
> I think I remember a scifi story that mentioned some character who worked in the one-time-pad shipping business.
A Fire Upon the Deep, by Vernor Vinge.
The strength of the system can be viewed from multiple angles. From a practical angle, applying one kind of commercial encryption on top of another type of commercial encryption turns it into a technically weaker, but unique cryptosystem. And uniqueness has value if you're just a single fish in a big pond.
For instance, if one single An0m customer had applied a caesar cypher to their communications, the cops might have skipped over him due to the unknown cost of putting dedicated crypto effort into one person in a massive dragnet.
And since you mentioned Schneier textbook, he also said that a good safe is the one that you give to your adversaries with the blue print of how it's made and still is uncracked, not the one that you dump in the middle of the ocean and ask your adversaries to crack it (security through obscurity).
PGP is still uncracked, if I'd become a criminal then public PGP with at least 8k bits key would be my choice.
It's not PGP that is uncracked, PGP is a set of tools built on top of RSA. RSA is still secure (other than brute force factoring) with appropriately sized keys.
The biggest problem with PGP isn't PGP itself, it's your opsec approach to everything else. Example... after decrypting a PGP payload - did you save it to disk unencrypted? Did the recipients to your messages save it unencrypted? Are any machines infected with keyloggers? PGP is a great tool, but still requires good opsec overall.
I think that if we are going to be concerned about multiple layers of encryption, as you say, then we should be equally concerned with things such as what encoding we use to send text with, or whether we use gzip or bzip. It would suck having to worry about all that; good encryption algorithms work regardless of how their plaintext is encoded, and home grown encryption is just another form of encoding.
A starting point might be to use battle-tested open source systems but subject them to detailed in-house analysis and audit.
2. It was fictional.
2. There were a lot of non-fictional organizations that ran just fine without any modern means. Genghis Khan conquered a lot of countries without relying on radio for communications or satellites for reconnaissance. Using a WhatsApp-like chat apps to communicate about criminal activities is very convenient, but opens a new vector of attack against you.
First, you need to generate large amounts of unbiased, true random data. If it is not true randomness, you have a stream cypher, and if you "rolled your own", probably not a good one.
They you have to store the one-time pad. It is usually too big to memorize. You have to store in on a device like a USB stick or a book, and guard it well.
Then, you have to share the secret, and for that you need a secure channel and that shouldn't rely on encryption, because it would miss the point. Essentially, you need to meet in person, in a secure location.
Then, you need to make sure that the one-time pad really is one-time. It should be securely destroyed after each use, preferably on both ends.
For something like coke smuggling you just need to know its on the way, get ready. So the OTP could be something as lame as "if you get a phone call from some rando who says 'Taste the Feeling'" then the next boat is full of coke, or if not, then the next boat is not full of coke". Actually terrible idea as taste the feeling was a coke company slogan a couple years back, but you get the general idea.
I had recently finished reading both books by Robert Mason, who started out flying helicopters for the Army in Vietnam and ended up smuggling literal tons of weed and got caught and did federal time. Pretty interesting autobiography. Anyway my comments fit pretty well with his description contained in his second book.
Mr Mason got caught by bad luck. There will always be small timers who do things small timer style who get caught by being verbose and oversharing, and to catch those we'll have "encrypted" smartphones.
Using enough data warehousing and artificial intelligence, eventually some algorithm would notice that every time some dude gets a phone call, next month the same boat gets a bill for servicing its water intakes, and a month later coke supply increases in .au decreasing the price. Might take a few times, but someone's getting caught.
The best part is if they go in shooting on a warrant and kill some random completely uninvolved people, it was all an algorithm's fault and nobody is to blame and I guess we just need more police involvement and surveillance to prevent future tragedies.
You might even schedule regular communications to avoid being caught by traffic metadata analysis.
An0m created two vulnerabilities to its users:
- It was specifically marketed to criminal entities. That is, it sharply reduced the search space. In a 33 bit world, An0m is 14 bits.
- It was specifically back-doored.
"Roll your own" avoids the 2nd case but not the first. By definition, rolling your own already reduces search space to the domain of interest. (Other means of evidence gathering may be needed, but should be reasonably viablle.)
Instead, what you want is:
- Blend in with the crowd.
- Utilise widely-shared communications protocols, implementations, and tools.
- Ensure that these have secure cryptographic methods and implementations.
- Audit the hell out of these and offer bounties for any vulnerabilities which can be demonstrated.
If at all possible, see to it that widely-used, generally-available communications tools themselves offer secure cryptographic methods and implemntations. And school your minions in their proper and effective use and limits.
> - Audit the hell out of these and offer bounties for any vulnerabilities which can be demonstrated.
The NSA backdoors will be pretty hard to find if they are there - It's not like you are going to see something like "If User == "NSA" Then Divulge_Key()". The backdoor is going to be something like a very subtle bug with how a particular crypto library is implemented, or some obscure buffer oveflow attack, and it probably won't even be discernible from an accidental bug.
In reality I doubt there is any way to know if the NSA can eavesdrop, it's a complete coin toss.
Avoiding NIST-recommended ciphers seems to be generally-advisable in this case.
There are other backdoors (see the case of Juniper Networks), but there's probably an enumerable set of pracices.
One helpful option is to use Free Software tools in which single actors are ulikely to be able to subvert the tool, and many have an interest in its integrity.