Mostly technical musings on open source software development
This project is maintained by liborty
One of the simplest and at the same time most secure forms of encryption is bitwise XOR (exclusive or) operation against a long symmetric key.
I have written a utility package Token Crypt that allows convenient compression and encryption of whole directories, using this method. XOR encryption is well known but TokenCrypt makes it efficient and convenient to use. It also adds recognition and effective compression of hexadecimal and base64files.
You might think that encryption and compression are two different subjects and you would be right. Nonetheless, there is a practical advantage to implementing them together: the keys are only as long as is absolutely necessary.
XOR is applied bit-by-bit to its two operands. The corresponding output bit is set to ‘1’ when the two input bits are different, else it is set to ‘‘0’. Conceptually, the operands can have any number of bits, processed in any order. In this case the operands are entire files.
This method is simple, secure and perfectly symmetrical: exactly the same operation with the same key decrypts the encrypted text back to its original form.
As long as the key is random, of the same length as the file being encrypted, and specific for just that one file, then this method (one-time cipher) is theoretically unbreakable. Any attacker would have to guess correctly every bit of the key file, which is not any easier than guessing the entire original content of the encrypted file. Given that the key is cryptographically random, it is actually even harder.
Apart from being easier to break, relatively short public and private keys for asymmetric encryption do have certain practical advantages over XOR. Above all, it is their ease of dissemination over the internet.
However, there are many encryption applications, where we may not want anyone else encrypting and/or reading our data. For example, when storing our private data files “on the cloud”.
XOR encryption has another very useful property that we will make good use of: it forms an abelian group, meaning that encryptions and decryptions with any number of different keys can be combined and the order of their application is immaterial to the result.
We shall now discuss some more interesting applications.
It was Alexandre Dumas and his Three Musketeers who had so far the best idea about what a true collective ought to be like: “all for one and one for all”. We adopt his model, where every individual counts, for our modern encryption.
Imagine a committee/group working on some super secret dossier. The problem is that some members of the group might leak it.
However, if every member cumulatively encrypts the dossier with his own secret key (and all the intermediate copies are deleted), then nobody has access until they have all decrypted it back again with their individual original keys. Every single member of the group is secure in the knowledge that nobody, not even all the rest of them, can leak it without his knowledge and permission.
A similar thing can be done with the public asymmetric keys but XOR is much simpler to use. Each member needs only one key. We should strive not to complicate things too much.
Now, suppose that a group needs to collectively issue some command or authorisation. Obviously, no individual member can have prior knowledge of the form of the (secret) authorisation command, else such a member could issue it alone. So the command has to be an encrypted secret which can only ever be revealed by being decrypted collectively, by all the individual members’ agreement, as above.
This is an additional requirement: the members must never see the command at all, before it is actually issued. This can be accomplished by X-oring all their individual keys together in advance and encrypting the secret with the resulting super key. Of course, it is necessary to delete the merged super key immediately after its use.
In order for electronic voting to be acceptable, it must fulfil these criteria:
Verifiability of voters: only those entitled to vote can vote.
Voters can be verified by the electoral authorities in the usual way. On production of their identity documents and proof of citizenship, the authorities will simply confirm the voter’s email address in the system as ‘authorised’. The ‘black box’ system then generates and mails them their anonymised ‘verified voter’ access key (API token). This token gives their local voting application rights to enter their vote into the online e-voting system (running on the server).
One problem remains, should the officials decide to create fictitious voters. However, discussing that would get us into deep issues of asymmetry of rights between the state and the individuals and it is perhaps better addressed another time.
Anonymity of voters: nobody else can connect a particular vote with a particular voter.
The ‘verified voter’ online access key is just a plain API token. It must not hold the voter’s identity information. The votes held on the system will be thus both anonymous and encrypted. The staff verifying voter’s identities do not have access to the automated access token generation process, so they can not match the voters to their tokens. In fact, the access tokens do not pass through their hands at all.
Verifiability of the vote: the voter must be able to check that the vote is recorded as entered and as intended and change it if necessary.
The voter then generates his own voting key on his own device, encrypts his vote with it, and using his access key enters the vote into the online system. Using his access key and the voting key again, he can subsequently verify his own vote. He can even change his vote by repeating the voting process (at any time before the election is closed). This will all be handled transparently by a simple to use local app. It is important that the app does not send the voting encryption key anywhere but uses it only locally at this stage.
Security: nobody should be able to ‘hack the system’.
The votes remain on the server in their encrypted form until the voting deadline expires. At that point the server switches to locked mode. The file(s) with the votes are collectively encrypted, protected ‘read-only’, and backed up.
Of course, as always, there remains a vulnerability to an ‘evil’ programmer or administrator. To this end all the system software must be open source, examinable by the public.
The server then requests that the voters forward their latest voting keys. It looks up their votes by their access keys and decrypts and counts the votes. The decryption keys can be sent now because the files are locked and can no longer be changed in any way.
If any unauthorised changing of votes took place prior to that, originating either from outside or within the system, it will be picked up because the decryption with the voter’s original true key will fail on a vote that has been tampered with. It is now acting as an e-signature.
The counting of votes must be repeatable by independent scrutineers.
The previous section outlined some useful ideas for deploying election committees (scrutineers) within an e-democracy. The candidates and/or scrutineers all encrypt the raw vote file(s) when the election is closed, thus satisfying themselves, that nobody else can tamper with them. This is equivalent to sealing the ballot boxes.
The counting itself and the results can now be verified by independent scrutineers, using their own software and working over the original sealed and encrypted files. They have to agree on the results.
One good thing about e-voting is that we can have plenty of recounts without any major inconvenience.
Finally, the system can be activated again, now in read-only mode. The changing of the votes is disabled but the voters can again verify that their votes are still there and intact. This amounts to very effective spot-checks, as any random voters can undertake to do this. Such a spot check would reveal any change to the vote done between the closing of the voting and the results being announced (presumably using the voting key that the voter has sent in to enable the counting). However, given that the files are write protected and encrypted by the scrutineers, this should not be possible.
Starting with a simple encryption, efficiently implemented, we have built up to a full blown model proposal for safe e-democracy. Any comments are welcome!