3 ms·

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

by 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.
- tempz 10y ago
  If the perceived importance of privacy is high enough, a fraction of people will spend days and weeks acquiring block cipher customization skills. The goal should not be all people, as that's doomed from the start. 15% is infinitely better than nothing. 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.
  - schoen 10y ago
    Backdoored tools are a pretty different threat from unknown cryptanalytic advances and should be addressed in different ways. A lot of research right now aims to address different backdooring methods (I gave a related talk at CCC a couple of years ago); a first step is to make sure that published source code corresponds to binaries and that all users receive the same software updates. Neither of these is guaranteed today, but we're making progress toward both. 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 https://en.wikipedia.org/wiki/Underhanded_C_Contest and then we've had https://underhandedcrypto.com/ https://underhandedcrypto.com/ and https://underhanded.rs/ 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 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.)

by tempz 10y ago

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.

tempz 10y ago
If the perceived importance of privacy is high enough, a fraction of people will spend days and weeks acquiring block cipher customization skills. The goal should not be all people, as that's doomed from the start. 15% is infinitely better than nothing. 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.
- schoen 10y ago
  Backdoored tools are a pretty different threat from unknown cryptanalytic advances and should be addressed in different ways. A lot of research right now aims to address different backdooring methods (I gave a related talk at CCC a couple of years ago); a first step is to make sure that published source code corresponds to binaries and that all users receive the same software updates. Neither of these is guaranteed today, but we're making progress toward both. 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 https://en.wikipedia.org/wiki/Underhanded_C_Contest and then we've had https://underhandedcrypto.com/ https://underhandedcrypto.com/ and https://underhanded.rs/ 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 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.)