"I’m not a security engineer, so what’s the benefit of using a nonstandard cryptographic protocol?"

Broadly speaking, the benefit is that if you have a keyhole view of the crypto world, you can google this and stackoverflow that online and get something that to your eyes appears simpler than using correct crypto, because correct crypto worries about keys, and revocation, and the keys are in a weird mix of formats, and certificates are complicated and have all these features you don't seem to need, and support for them is more mixed and less widely available than you'd like. Your simpler crypto seems to work, and it might be "faster", and it was easier to bash together one function that "uses" AES directly and puts out a stream that "looks encrypted" than it is to worry about all the things it takes to use crypto correctly.

None of that is sarcastic; especially if you don't stumble upon libnacl or some other library designed to be easy to use while still being correct, using crypto correctly is actually a good deal harder than misusing a couple of primitives to get something that superficially works. I mean, again no sarcasm, you can figure out how to bash something together with AES256 primitives faster than you can even figure out how to run a too-simple-for-your-needs Certificate Authority, which even if you do Google up the right scripts is still annoyingly difficult in my experience. And that's only a single element of what you may need to do for your app to be secure.

In terms of any other sort of advantage, there basically isn't one. It's the above advantage that is why we keep seeing home-grown crypto all the time.

Now, getting your use of the crypto primitives correct is much harder than getting your use of existing solid libraries correct. Unfortunately, misused crypto doesn't usually crash or segfault or fail visibly; it still produces binary gibberish visually indistinguishably from the binary gibberish solid libraries will produce. It just turns out to be low-quality gibberish that won't secure you or your users. But no segfaults, crashes, errors, warnings, etc.

The only reason to use nonstandard crypto is that you think you are smarter than the entire crypto industry. ProTip: you are never smarter than the entire crypto industry.

You forgot the other reason: backdoors

Fully agree. That's the primary issue associated with bringing a piece of critical civic infrastructure, such as voting, into the digital domain. Who builds, maintains and secures the tech? Certainly not the government. The govt only acts as a collective entity to support and promote strong tech-driven markets (it should at least in theory). I do hope that more individuals in the crypto industry get involved politically because of their technical wherewithal.

There's benefit when working in low-security environments. A custom crypto model will make your process harder to understand by a reverse engineer. This adds some security by obscurity, but almost certainly weakens actual security.

Let's say you just want to store and restore data on a user's computer, but want it to be difficult to read by an outside program. In this scenario, using an established algorithm makes it easier to decipher your encoding, and by nature if the encryption and decryption happens on the user's machine then you have to store the public and private keys on the user's system. There's no other way to accomplish this task if offline is a requirement. So in this case, obscurity has value in deterring reverse engineers.

I’m not sure that infra-as-code belongs on that list.

IMO it's a security problem in practice - it means that you have a lot of organizational resistance to doing things like regular software updates, because you end up with this one server that's been hand-crafted that people are too scared to touch. Or, analogously, if you want to introduce some new sort of authentication/auditing/etc. protocol to the system, people will worry that they won't be able to find every use of the old thing and won't make the new thing mandatory. It also means that it's a lot harder to test changes, because you don't know what you need to set up to get a full test/QA environment going.

It's not a vulnerability in itself, but the fear/stop energy created by artisanal small-batch infrastructure is a good way to set yourself up for vulnerabilities being exploitable. (See, for instance, Equifax being hacked by a two-month-old Struts vulnerability - you can theoretically argue that Equifax is a big company and should carefully audit their dependencies, but a much more practical argument is that Equifax should have been ready to patch within days, at most, of the vulnerability being announced.)

The actual ToB report identifies another reason which I didn't think of:

> Ensure that all backend infrastructure is re-provisioned between elections and not shared between elections/clients. Each server should also receive its own unique SSL certificate and credentials. Use infrastructure-as-code tools like Ansible and Terraform to automate and manage provisioning.

Apparently there are two concrete problems:

1. All Voatz backend servers share a single wildcard certificate, and they think that automated provisioning would reduce the incentive to do things like this.

2. Every Voatz election uses a custom iOS/Android app delivered via TestFlight / Google Play Beta, because of some design choices in the protocol related to having a single shared backend (S3, MongoDB, etc.). They think that if there were infrastructure-as-code for the shared backends, it'd be easier to provision one instance per election and easier to make the client change to use a single client for each election, blocking potential attacks on the page that links you to the sideloaded app.

It also enhances auditability since you can keep a record of all changes in code and run the tooling to see if resources are changing outside of how they were configured. Without those tools, you'd have to develop your own to meaningful ensure infrastructure is setup correctly (it's not practical to hand inspect hundreds or thousands of small components)