7 ms·

Binney is suggesting the proper approach - safe manual customizations that require manual cryptanalyzis, which is not scalable. If only few % of users start to

by Zilroy 10y ago

Binney is suggesting the proper approach - safe manual customizations that require manual cryptanalyzis, which is not scalable. 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.

schoen 10y ago
> 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/ 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!
- tempz 10y ago
  This is true for manual (mental) text scrambling. I remember the time when I thought I invented the keyboard-pattern passwords. 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.
  - schoen 10y ago
    I agree, but I wonder about how many people can be induced to devise a custom block cipher and somehow communicate an implementation of it to their communication partners in a way that isn't systematic and doesn't depend on the security of other ciphers. (Presumably you lose the marginal benefit if you make a popular "make your own block cipher and share it with your friends" tool!)
    - tempz 10y ago
      It depends how truly important the security is for someone. 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.
eternalban 10y ago
This is basically security by obscurity.

by Zilroy 10y ago

schoen 10y ago

> 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/ 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!

tempz 10y ago
This is true for manual (mental) text scrambling. I remember the time when I thought I invented the keyboard-pattern passwords. 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.
- schoen 10y ago
  I agree, but I wonder about how many people can be induced to devise a custom block cipher and somehow communicate an implementation of it to their communication partners in a way that isn't systematic and doesn't depend on the security of other ciphers. (Presumably you lose the marginal benefit if you make a popular "make your own block cipher and share it with your friends" tool!)
  - tempz 10y ago
    It depends how truly important the security is for someone. 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.

eternalban 10y ago

This is basically security by obscurity.