MailClad E-voting open-source open-systems architecture

I believe that you can't design a proper system without getting two things straight at the start.

Why is Philosophy so important? Philosophy forces one to think about the many important concepts and questions that must be considered when designing a system. What are you protecting against, what approaches should be taken. What lessons from the past must you keep in mind. I love doing this with many famous quotes, in part because they were much smarter then I am, and also because if you disagree then go take it up with them. So lets begin.

So what can we trust?
Any process watched over by several opposing parties is safe.
Any algorithms based on Information Theory and Mathematical Laws.

"I have made this letter longer than usual, because I lack the time to make it short" (Je n'ai fait celle-ci plus longue parceque je n'ai pas eu le loisir de la faire plus courte) - Blaise Pascal, Lettres Provinciales (1656-1657), no. 16.

"The challenge is keeping it simple while providing the people with functions. This is harder to do. Anyone can make something complex." Dauphin A German Chair company

KISS, Keep It Simple, Stupid or maybe Keep it Short and Simple, I like the first one.

"A program with a colorful GUI is like a woman with too much makeup. Shiny on the outside - awful on the inside."

Security by Obscurity - A term applied by hackers to most OS vendors' favorite way of coping with security holes -- namely, ignoring them, documenting neither any known holes nor the underlying security algorithms, trusting that nobody will find out about them and that people who do find out about them won't exploit them. This "strategy" never works for long and occasionally sets the world up for debacles like the Great Internet Worm of 1988, but once the brief moments of panic created by such events subside most vendors are all too willing to turn over and go back to sleep.

It far too common for Close Source software companies to rely on this method for security. It's cheaper in the short term.

System designers should assume that the entire design of a security system is known to all attackers, with the exception of the cryptographic key.

The law was one of six design principles laid down by Kerckhoffs for military ciphers. Translated from French, they are:

The system must be practically, if not mathematically, indecipherable;
It must not be required to be secret, and it must be able to fall into the hands of the enemy without inconvenience;
Its key must be communicable and retainable without the help of written notes, and changeable or modifiable at the will of the correspondents;
It must be applicable to telegraphic correspondence;
It must be portable, and its usage and function must not require the concourse of several people;
Finally, it is necessary, given the circumstances that command its application, that the system be easy to use, requiring neither mental strain nor the knowledge of a long series of rules to observe.

Kerckhoffs' doctrine 1883

Bruce Schneier ties it in with a belief that all security systems must be designed to fail as gracefully as possible:
"Kerckhoffs' principle applies beyond codes and ciphers to security systems in general: every secret creates a potential failure point. Secrecy, in other words, is a prime cause of brittleness.and therefore something likely to make a system prone to catastrophic collapse. Conversely, openness provides ductility."

By being closed source companies like Diebold loose the benefits of having an army of software developers reviewing source code for bugs, security holes and other problems. Open Source projects benefit from the expertise and wisdom from 1000's of the world best programmers. So by being part of an Open Source effort many improvements happen that no one company could ever do on their own.

This is very much same philosophy as the Private vs. Public research in almost any scientific field. If you keep your research to your self, then you don't get credited for it. Also your work never gets confirmed, there is a good chance of deluding yourself about how secure and bug free your code is. (take Microsoft for an example)

The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.)
From a really eye opening paper Reflections on Trusting Trust by Ken Thompson 1984

From Anonymous Coward:
I would have thought that the fundamental problem with closed source, in this particular application (not in general), is the fact that it is closed source. For elections to work it is important that the entire process be open to scrutiny. If something goes wrong, you need to be able to look through and find what/where... even if the only remedy is to say "bug x in function y of the source code makes this result invalid, we need to vote again using a different system (eg. paper)". But if the source is not available for scrutiny, you can't do this... you can look at the results and say "that's a bit odd", but you can't trace back to probable cause. This is precisely what closed source software can never get right, whereas OSS does by definition

From Dachannien:
But if closed source polls can't get it right, what makes us think that OSS polls can?

The difference is that, with an OSS voting system, if there's a problem with the code, the public will (be able to) know about it.

Compare that to Diebold and ask yourself how likely it is that they'd be forthcoming with crucial details if and when something goes haywire with their electronic voting machines.

Any cryptographic system based on Primes can be cracked with sufficient CPU power, or Quantum computers.
* This covers all DES, AES, RSA, PGP and public key systems
Cryptography often seems to ignore information theory, specifically what is needed to extract a signal from noise or alter it.

Mail Clad Philosophy

Why do people believe OSS == trustable?