Liquid Feedback anonymisieren

Liquid Feedback ist ein System, um Politische Anträge zu verfassen, Änderungsanträge einzureichen, Unterstützer für diese Anträge zu sammeln, und über sie abzustimmen.

Die Piratenpartei (Allen voran Landesverband Berlin) testet dieses System momentan.

Da die Piraten elektronischen Wahlen nun skeptisch gegenüber stehen, gibt es natuürlich Probleme mit dem System. Wahlen haben nachvollziehbar zu sein, schön wäre auch, wenn sie anonym sein könnten (Wahlgeheimnis).
Die Korrektheit der Wahlen wird in der FAQ auf der Projektwebsite als wichtiger als die Anonymität bezeichnet (Eine Wahl, die nicht überprüfbar korrekt ist, ist natürlich nicht viel wert); deshalb wird auf die Anonymität verzichtet, da die Funktionen von Liquid Feedback wohl sonst nicht technisch umsetzbar wären.

Projektwebsite: http://liquidfeedback.org

Das sehe ich anders.

Eine überprüfbare anonyme Wahl halte ich für möglich, wobei
1. Überprüfbar bedeutet, daß jeder Wähler die korrekte Zählung aller Stimmen, sowie den korrekten Eingang der eigenen Stimme überprüfen kann
2. Eine Stimme, die ein Delegierter (nach dem Prinzip der liquid democracy) für einen Wähler bereits abgegeben wurde, von diesem wieder eingezogen und durch eine echte eigene Stimme ersetzt werden kann.

Das soll so funktionieren:

Insgesamt sind für das ganze Verfahren 2 Techniken vonnöten:
1. Asymmetrische Verschlüsselung
2. Blind Signatures die zur Verschlüsselung passen

1. Wahltokens

Es gibt einen Wahlserver, der "Wahlzettel" annimmt. Nennen wir ihn "Urne". Ein Wahlzettel besteht aus einer zufälligen Bitsequenz (Wahltoken) und einer Wahl (Wahl heisst hier 'dafür', 'dagegen' oder was die Abstimmung grad hergibt.)

Ist der Wähler im Besitz dieses Tokens, ist die Verbindung Wähler<->Token aber ansonsten geheim, so kann der Wähler den korrekten Eingang seines Wahlzettels prüfen, da nach der Abstimmung einfach alle Stimmen veröffentlicht werden können. Niemand anders kann allerdings Wahlzettel und Person verknüpfen, da niemand sonst die Tokens der anderen kennt.

2. Authentisierung
Um nur zur Wahl zugelassene Menschen (zB nur Piraten) Wahlzettel an der Urne abgeben zu lassen, muß ein geeigneter Authentisierungsmechanismus her.
Folgendes halte ich für praktikabel: Es gibt einen Authentisierungsserver (Auth-Server).
1. Der Wähler generiert sich sein Wahltoken
2. Er meldet sich am Auth-Server an. Dieser prüft die Zulassung zur Wahl, und markiert den Wähler als jemanden, der gewählt hat. (oder nach abschluss des Verfahrens gewählt haben wird)
3. Der Wähler 'blindet' sein Wahltoken (siehe oben: Blind Signatures)
4. Der Wähler schickt sein geblindetes Token an den Auth-Server
5. Der Auth-Server signiert das Token und schickt es dem Wähler zurück.
6. Der Wähler kann das signierte Token entblinden, und mit einem lesbaren, signierten Token an der Wahl teilnehmen.
Die Signatur bietet der Urne die Möglichkeit, zu wissen, daß der Wähler zur Wahl berechtigt ist. Dabei erfährt die Urne nicht die Identität des Wählers, und der Auth-Server wegen der Verblindung das Token nicht. Beide (selbst bei Personalunion) können also nicht (ausser durch zeitliche Abläufe) Wähler und Token zuordnen.

3. Delegierte

Jeder Wähler soll seine Stimme an einen beliebigen anderen Wähler delegieren können. Diese nenne ich Delegenten, jene Delegierte.

Der Auth-Server weiß, wer schon gewählt hat (s.o.) und weiß auch (durch Vorgabe), wer wem seine Stimme delegiert hat bzw. wer berechtigt ist, für wen abzustimmen.

Um das jetzt anonym und funktionierend hinzukriegen, muß ich etwas ausholen:

1. Das Wahltoken-Verfahren läßt (m.E.) nicht zu, daß Stimmen, wenn sie einmal abgegeben sind, in ihrer Wertung verändert werden. Da dies aber nötig ist, bei einer nachträglichen Abgabe einer eigenen Stimme eines Delegenten (Delegent +1, Delegierter -1) muß tatsächlich für jede Stimme ein Wahlzettel abgegeben werden.

2. Der Delegent muß seine Stimme überschreiben können. Das kann er aber nur, wenn 1. die Urne das zuläßt (gut, das tut sie), und wenn er 2. sein Wahltoken kennt.
Desweiteren (und das ist wichtig) muß hier sichergestellt sein, daß es wirklich das Wahltoken der Stimme ist, die der Delegent auch überschreiben darf. (und nicht eine fremde).

Hier also das Verfahren, wie ein Delegierter E fuer einen Delegenten D abstimmt:
1. E meldet sich beim Auth-Server an, und teilt mit, er möchte für D abstimmen. Der Auth-Server ist in der Lage zu entscheiden, ob das ok ist (Hat D schon abgestimmt, oder ist E gar nicht von D delegiert, dann gehts zB nicht.)
2. E generiert eine grosse Zahl (>1 und zB n) sogenannte pre-Tokens, die ich auch Lösch-Tokens nenne.
Für jedes dieser Pre-Tokens generiert E eine verschlüsselte Version, die nur D lesen kann (Verschlüsselung per Public-Key von D), eine Version die nicht verschlüsselt ist, aber gehasht wird (zB SHA1) und dann geblindet wird, und eine Version die auch nicht gehasht, sondern nur geblindet wird.
3. Alle diese Tripel werden an den Auth-Server geschickt.
4. Der Auth-Server sucht sich ein Tripel zufällig aus, daß er _nicht_ lesen können will, und teilt dies E mit.
5. E schickt alle Verblindungsfaktoren an den Auth-Server, mit Ausnahme des ausgewählten.
6. Der Auth-Server kann nun die verblindeten Teile entblinden, verhashen, mit dem Public-Key von E verschlüsseln, und prüfen, ob die Tripel korrekt gebildet sind. Wenn ja, vertrauen wir darauf, daß auch das ausgewählte und für den Auth-Server eben nicht prüfbare (da nicht lesbare) Tripel korrekt ist.
7. Der Auth-Server sendet die verschlüsselte Version des Pre-Tokens an D. Damit ist D in der Lage, seine Stimme später zu überschreiben, da er das Pre-Token kennt. (Wie das geht, folgt gleich).

8. Der Auth-Server signiert die geblindete, gehashte Version des Pre-Tokens und sendet sie an E zurück.
9. Er führt eine Wahl durch wie in "1. Wahltokens" ausgeführt, wobei das gehashte Pre-Token das Wahltoken darstellt.

4. Überschreiben von Stimmen

D hat seine Stimme delegiert, E hat für ihn/sie gewählt, und nun möchte D aber doch seine eigene Stimme wahrnehmen. (wenn D selbst Delegierter ist, kann das Verfahren leicht aufgebohrt werden).

Dafür muß D nun 2 Dinge tun. Überschreiben der Wahl ist nicht möglich, da damit die Anonymität nach oben flöten ginge. D.h. Das Wahltoken der neu abgegeben Stimme muß ein neues sein. D.h. zerteilen wir das Überschreiben in Löschen und neu wählen. Neu Wählen muß nicht erläutert werden, aber wie kann gelöscht werden?

Die Urne kann natürlich nicht einfach Stimmen löschen, wenn man ihr (unauthentisiert, denn die Urne nimmt keine Authentisierung vor, dafür ist der Auth-Server da) befiehlt, einen Wahlzettel, gewählt durch das Wahltoken, zu löschen. Dann könnte jeder mißliebige Stimmen einfach löschen.

Aber: Wir haben ja das Pre-Token. Wie oben schon erwähnt, heisst es auch Lösch-Token. Man gibt es der Urne, und die Urne verhasht es selbst zum zu löschenden Wahltoken. Damit ist sichergestellt, daß man auf jeden Fall Zugang zum Pre-Token haben muß, etwas, daß man nicht durch Lesen der veröffentlichten Abstimmung gewinnen kann.

Es wäre schön, wenn sowas implementiert werden könnte, vielleicht sogar direkt in Liquid Feedback eingebaut werden könnte. Mal schaun.
Desweiteren wärs natürlich total toll, wenn ihr Nerds mich alle ausfragt, weil ich mich unklar ausgedrückt habe, und mir erklärt, warum mein Verfahren nicht funktioniert.

Ahoi