> There is no automated tool that can cryptanalyze in real time someone's naive but unique idea what crypto should be.

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

https://www.xkcd.com/936/

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!