[tempz]

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]

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

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.)

[tempz]

Zero days, backdoors and unknown cryptanalytic capabilities have similar if not the same effect on centralized systems.

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...

[tempz]

> it would be helpful to have good guidance for secure composition of cryptographic primitives

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.