If only few % of users start to roll out their own custom crypto, not stronger than ROT-13, that would completely overwhelm the interception industry, including the state-level players. There is no automated tool that can cryptanalyze in real time someone's naive but unique idea what crypto should be.
In other words, this is shifting the paradigm where few high priests of the open source crypto design few key components for billions to use, and cryptanalysis has to deal with only few problems which are eventually automated, to the problem where tens of thousands of brains construct their own weird crypto which has to be manually cryptanalysed. Cryptanalyzers would need to employ millions to achieve this.
Feel free to do this on top of the blessed crypto stacks.
This might depend on how big the possibility space is. For example, you could imagine someone making a similar argument about transformations to passwords (like adding digits or punctuation, writing words backwords, changing letters to symbols that resemble them visually, and so on). A lot of people have independently come up with these transformations and correctly reasoned that they expand the space of possible passwords and add uncertainty (entropy) for someone trying to guess a password, especially if they're used in an inconsistent rather than systematic manner.
Still, password crackers have had great success explicitly enumerating this possibility space and brute forcing against it, basically since each transformation that people are particularly likely to think of only adds a relatively small amount of uncertainty, on the scale of the overall password cracking problem. This was already recognized at the time of Alec Muffet's Crack program (which let you use manually-specified transformation rules to expand your password-guessing dictionary), and attackers' heuristics and databases have only gotten more powerful since then. It's also discussed in the Diceware xkcd
Here Randall argues that the substitutions added about 11 bits of entropy, plus "a few more bits" because of uncertainty about which ones were used. That wasn't enough to defeat realistic adversaries in this context.
I'm concerned that a lot of text obfuscation methods that people would think of will fall into this category and perhaps provide only a handful of bits of additional entropy; for example, they might use familiar encodings that are well-known to puzzlers (like Morse code, binary, semaphore, the NATO alphabet), they might write things backwards or in a customized order at an n-gram level, they might use what is effectively a simple substitution cipher, and a few other possibilities.
I don't think it would be difficult to try an extremely large number of these possibilities, combined with sophisticated statistical tests for plaintext. I bet versions of these analysis tools that work pretty well were developed decades ago. Computers are very fast and combinations of brute force and statistical analysis are very powerful.
To be clear, I wouldn't discourage people from doing this (on top of standard communications security methods), and I would agree that it might sometimes provide a benefit. But I would discourage people from assuming that their homegrown text obfuscator is giving more benefit than using "Tr0ub4dor&3" instead of "troubador" as their password (a non-zero benefit, yet an inadequate benefit against sophisticated adversaries).
Maybe there's a way to change that picture, but I guess it would involve having people spend a lot more time studying and thinking about it, in the hope of greatly expanding the space of possible encoding transformations that they're capable of thinking up. And then you still have to be careful of statistical analysis. We might think we're very clever by inventing a new transliteration of our language into a script that was never before used to transcribe it, and then a statistical tool may still successfully analyze that transliteration as a simple substitution cipher and break it automatically!
However, if this home-brewed crypto involves coding (and requires users to learn an appropriate language), then it's possible that the entropy harvested from brains of such novices will be orders of (decimal) magnitude over the simple text scrambling.
For example, take simple DES implementation and customize S boxes and/or key generation phase. Do not publish the program except to your peers. Yes, S boxes filled with your dog's vaccination report are likely more sensitive to differential cryptanalysis - but how much ciphertext would that take, not to mention the analyst's time?
We are not talking here about someone specifically targeted. Custom obscurity works great when practiced massively, as de-obscuring has to be done manually in each case.
The bigger issue is whether privacy and secrecy should be simple so that anyone can use it. We may be well past that - standardized security is obviously dead in the water. If security is important and affects one's life, then one should invest effort in it as the one invests efforts in hygiene, education, car maintenance etc.
The requirement that security must be simple so that even idiots can use it is a diversion, a fallacy that imposes inherently weak crypto on all. This is the biggest lie plaguing crypto since the first crypto war.
Literacy started in the similar way, and it's not easy for everyone to learn to read and write (functional illiteracy rarely goes below 10% or so.)
I'll make a wild guess that 15-20% of the general population can learn in few months to tweak working code into working code. There goes surveillance.
Again, nothing prevents one to run this on the top of the 'proven' security stacks. CPU is cheap.
And in terms of spending, say, 3 hours learning to use PGP and/or get your friends to use it with you vs. 3 hours trying to write your own block cipher and/or get your friends to use it with you, I'd expect almost everyone in the world to get more privacy benefit from the former.
To (ab)use another analogy, look at the history of the tobacco (ab)use. It was hard to get people not to indulge in it just because they will have problems 20 years from now, which is close to the surveillance damage. It took years and huge efforts to cut down the tobacco use.
Getting the people I e-mail with most to use PGP encryption with me would probably require 20 minutes to 5 hours, probably in person, with each of them. That is likely more time than people spend on professional dental care annually and, if I'm doing the setup, I have to spend that time with each correspondent.
Getting them to also use some kind of homegrown obfuscator or custom block cipher with me (but not with their other correspondents?) is another effort of several hours per person, again requiring meeting in person with each correspondent.
Both of these mechanisms are then very fragile if a given correspondent changes devices or operating systems.
You might argue that, for each person, learning how to use a tool like GPG is on par with getting annual dental checkups (possibly annoying and time-consuming, but just a few hours, and with potential hard-to-foresee benefits over the long term). And that's fine, but if we're still talking about adding completely homegrown custom layers intended to defeat automated cryptanalysis, the picture has gotten a lot more complex. By definition, the people adopting these solutions have to design and deploy them in a customized, personalized way, to avoid having large populations of people adopting the same tools and techniques. If this is supposed to be reliable (and somehow coexist with other custom techniques, so that Alice and Bob can use one homegrown obfuscation layer while Bob and Carol use a completely different one!), I expect it would be an order of magnitude more effort even supposing that most of the participants are already capable software developers.
I mean, maybe there's a way to extend OpenPGP so that you declare a "custom cipher" on top of the main ciphersuite and then implement it as a plugin so you "just" have to do the core work on your custom thing and not on the surrounding key exchange mechanisms, data format, and e-mail client integration... but it still represents a massive amount of additional work for each pair or small group of communicating parties, even given this hypothetical infrastructure.
The task at hand is to elevate the perceived importance of privacy and the importance of self-defense/education to the point of writing some insecure (but unique) code. The latter is the novel point in this discussion.
Currently, the dogma is to explain the importance of privacy, and then point the newly aware audience to use one of the 2-3 options developed by 2-3 teams/companies. This will never work towards general privacy, because if all Internet users started using Signal, PGP, Snapchat etc. tomorrow, the day after tomorrow these products will be backdoored, and backdoored version pushed as an update, as these 2-3 teams have addresses and families, and engineers and CEOs in general do not respond well to anal probes, audits and accidents. This has happened so many times so far, that it boggles the mind how anyone with a shred of integrity can preach centralized pret-a-porter security solutions.
I do not know how to clearly demonstrate the importance of privacy today and the fact that you don't have centralized friends.
Showing smoker's lungs in formaline was easy.
A trickier problem is bugdoors, where someone intentionally introduces an exploitable vulnerability into a code base. The underhanded C contest points at some of these risks
https://en.wikipedia.org/wiki/Underhanded_C_Contest
and then we've had
https://underhandedcrypto.com/
and
https://underhanded.rs/ (which was just mentioned here on HN)
It seems likely that this approach has already been used against some important software somewhere, regardless of the specific methods and incentives used to get it into the code.
Maybe the experience gained from these contests will point at ways of avoiding bugdoors in the future, whether formal methods, static analyzers, changes to language specifications, coding standards, improved auditor skill, or something else. (I'm personally a bit hopeful about formal methods; they've seen an encouraging new level of success in the academic world over the last few years.)
There are definitely principal-agent risks in having everyone use Signal or GPG. But you're not going to invent something as secure as AES by yourself, nor something as secure as Signal or GPG. The crypto world has made massive advances in the last couple of decades by respecting Kerckhoffs's principle. There are worthwhile arguments like
https://news.ycombinator.com/item?id=11854576
that you can get a security benefit against some threats by adding some non-globally-shared obscurity layers. That doesn't mean you can go off on your own and do as well as publicly-scrutinized stuff does.
I think I should get the authors of "Imperfect Forward Secrecy" to opine on this. They may have identified one of the decade's biggest security problems from cryptographic monoculture, but still I doubt they would agree that we can make much progress with home-grown communications security solutions. (But as discussed elsewhere in this thread, it would be helpful to have good guidance for secure composition of cryptographic primitives, so if you're not sure of one layer and want to add another, you can at least do so in a way that doesn't make things worse.)
I am skeptical about open source efforts being a match for (tens of) thousands well-paid professionals working for well-funded organizations, 5 days a week, year after year. It just doesn't make sense that point efforts of few can accomplish anything sustainable and effective against such adversary. Yes, open source people are brilliant, heroic, etc. It doesn't matter. These efforts need to be distributed from dozens to tens of thousands, and that will begin to be the match for the organizations we are dealing with.
To eliminate all issues and pushbacks about basic security of home-brew crypto (although I think that in the big picture it doesn't matter - you are either targeted or they don't have resources to figure out your particular ROT-17.5), it should always be used on the top of your favorite official crypto stack. So don't worry about being inferior to AES - use AES as well if you trust it.
Home-brew crypto works. In the latest Stone's film, the whistleblower takes out flash storage hidden in Rubik' cube. It needed to work only once, for him. If it is important, people will do it.
In the big picture, we may be dealing with the elitism of brain-work. It feels warm and fuzzy to be a member of an elite group helping billions. But as in other human enterprises, the real and sustainable success happens only when such brain-work gets widely distributed. While not the easiest thing in the world, crypto is not esoteric rocket science, and the notion that those few that had to resort to programming for living and fun are somehow more mentally capable than the rest 99.9999% is pure bs.
These threads illustrate some of these points:
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
https://www.mailpile.is/blog/2016-12-13_Too_Cool_for_PGP.htm...
Yes.
An easy-to read program executing generic Feistel-net block cipher with exchangable/modular S-boxes and trapdoor functions would be great. I'm looking into something like that.
Do you have an example of how you might do that? Something like (real basic example) reversing a json payload?
{"key": {}} becomes {{}: "yek"}
Or is that too simplistic?
This also reminds me of when somebody here wrote about meeting one of the cryptographers at a con for SHA3 (Blake?) and the guy shrugged off his efforts saying it was all for fun meaning whatever device you have is so completely back doored already either through sabotaged/weakened standards or outright (proprietary microcode) that believing any algorithm can keep a secret from nation state adversaries is laughable.
Well, yeah, it is.
Defence against (crypto-buzzword) state-level actors (SLAs) doesn't start with gpg and FDE, rather, with operational security, or, even better, not being a worthwhile target in the first place (if your briefcase of secret documents is already on CNN there is no need to infiltrate your stuff beyond gaining assurance that you don't have another briefcase - which is the thing you want to proof as publicly as possible to convince your highly paranoid adversary)
There is that saying "never trust a computer you can't throw out the window". Computers are networked. You're trusting a network of computers, even if you don't use "networked functionality". Can you throw the internet out the window? Probably not! Hence, don't trust computers. People who trust computers to keep their secrets are foolish¹ (Trottel), so just don't.
¹ Notice how governments²³ trust computers to keep their secrets safe, and how admirably and totally that failed. Ask yourself, what wasn't leaked by Snowden? Stuff that wasn't in any computer in the first place!
² Or how celebrities trusted computers to keep their dickpics safe.
³ Or how companies trusted computers to keep their business secrets, well, uh, secret.
To make my point another way: Computers are for disseminating information. If secrecy is more important than dissemination, then don't use a computer.
I think a big part of them not commenting on the issue was that they didn't know what Snowden had and they got caught in a number of lies early on.
that off my chest.
"protocol level" is the order of the bits. for example the octets in the tcp protocol.
"rearranging the payload" in this case is moving around those octets. and while of course it would work, is a bit simplistic. (so yeah, yek not far off)
the "Best" solution imho is to chain more than one cipher together. "like truecrypt does". for example, if you are using a pre shared key, use that key to encrypt the dhe with a symmetric cipher and a nonce. or some other non trivial obfuscation.
but the point is valid, even simple obfuscation requires human intervention, which breaks mass surveillance en mass.
-- Mount black bag attacks on your premises. -- Snoop the networks of internet service providers.
On the other hand, most or all of the following are true of my keys-to-the-kingdom email account (the one from which most other passwords can be reset):
-- It is very unlikely to be hacked by any information guesses of my password, social engineering of my "secret question" information, shenanigans with my mobile phone, etc.
-- It is with a provider who seems less likely to get hacked than even Yahoo.
-- It has security that would be hard to brute force.
-- It has a unique password that I don't use on other, more vulnerable accounts.
Even so, I assume that all my communications are available to the US government, at least by after-the-fact subpoena if not actually real time.
Indeed, not even our governments are safe from the government. like when they forced backdoors in juniper routers, then used juniper routers in government facilities. resulting in widespread compromise of most if not all government facilities and the loss of billions of dollars r&d advantage.
At least they put tons of effort into securing the voting system and didnt let a russian stooge get declared leader of the free world tho. so there is still some hope.
for us tho. encrypted at rest, and intrusion detection generally good practice.
This makes me a bit uneasy: would a parallel brute force search would be much more difficult for elliptic curves than it would for symmetric cyphers? Why? By the way, a similar problem arises with poly1305. I'm missing something.
The reason curve25519 has a security level of only 128 bits is that ECDLP takes time proportional to the square root, so half the number of bits (https://en.wikipedia.org/wiki/Elliptic_curve_cryptography#Ke...).
As for poly1305, it actually uses not one, but two separate 128-bit keys. The authentication tag computed using the first key is encrypted with the second key. For a brute force search, it should be as hard as breaking something with a single key of around 256 bits.
Breaking e.g. AES key of n bits requires you to try 2^n combinations, but the actual computation per key is very fast.
[1] https://crypto.stackexchange.com/questions/13249/why-can-ecc...
A batch attack on asymmetric ECDSA like curve25519 costs MORE than 2^128, it just grows logarithmicly instead of linearly.
That's why.
The trade-off there is that it might draw unwanted attention. Such an approach may be more suited for use inside of a message already encrypted using standard means.
It's worth noting that if there's no network interception angle, the NSA can easily penetrate all but the most hardened systems should they be so inclined.