5 ms·

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 cr

by 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.
  - schoen 10y ago
    Well, it's been pretty tough to get people to adopt some existing crypto tools like PGP that represent a lower bar than writing your own crypto primitives. I'm completely sympathetic to the idea that this kind of literacy could lead to habits and practices that make surveillance harder and that that would be a great thing, but it seems like ubiquitous use of existing peer-reviewed crypto tools represents much lower-hanging fruit. 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.
    - tempz 10y ago
      Well, if we agree that a moderate effort (comparable to dental checkups) would make a big and positive difference in the surveillance arena, and yet assume that 'people' cannot be induced to do it, perhaps we are dealing with ideology and indoctrination, not with technical problems. If so, no technical solution can be applied before the ideological issues are taken care of. 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.
      - schoen 10y ago
        I agree with the ideology observation and probably also with the tobacco analogy, but I don't think I agree with the dental checkup analogy; here the difficulty is network effects. 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.

by tempz 10y ago

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.
- schoen 10y ago
  Well, it's been pretty tough to get people to adopt some existing crypto tools like PGP that represent a lower bar than writing your own crypto primitives. I'm completely sympathetic to the idea that this kind of literacy could lead to habits and practices that make surveillance harder and that that would be a great thing, but it seems like ubiquitous use of existing peer-reviewed crypto tools represents much lower-hanging fruit. 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.
  - tempz 10y ago
    Well, if we agree that a moderate effort (comparable to dental checkups) would make a big and positive difference in the surveillance arena, and yet assume that 'people' cannot be induced to do it, perhaps we are dealing with ideology and indoctrination, not with technical problems. If so, no technical solution can be applied before the ideological issues are taken care of. 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.
    - schoen 10y ago
      I agree with the ideology observation and probably also with the tobacco analogy, but I don't think I agree with the dental checkup analogy; here the difficulty is network effects. 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.