Benutzer Diskussion:Haibaer/Token-Generator

Probleme / Fragen

Magst Du anhand dem hier ergänzen:

• ob die da postulierten Probleme auch siehst
  • Klar, das System hat durchaus Nachteile. Auch muss man immer Zugriff auf den Key haben; man kann nicht mal eben im Internet-Cafe oder bei Bekannten/Freunden abstimmen
    • ich meinte speziell die "Zeiteliten"- und "Vertrauen in Krypto"-Probematik
• wenn ja: wie du sie lösen möchtest, wenn nein: warum sie nicht auftreten
  • Hier brauchen wir einen Klicki-Bunti-Client der auf so vielen Betriebssystemen verfügbar ist. Alternativ kann man natürlich auch einer fremden Webseite vertrauen, wo jemand eine tolle Oberfläche bastelt
• inwiefern die hohe Anzahl von "Einweg"-PGP-Keypairs ein Problem werden könnte
  • das müsste man mal in einem Lasttest herausfind
    • Ich meinte eher das es doch technischer Irrsinn ist, bei angenommenen 200 Anträgen vorm BPT mehrere 100T Keypairs zu erstellen, die genau einmal gebraucht werden. Wäre eine "Token-CA" da nicht geeigneter, die könnte die Tokens mit Zertifikaten verschlüsseln/verschicken die automagisch nach Abstimmungsende auslaufen.
      • Das ist natürlich ein Punkt. Allerdings sollte hier beachtet werden, dass dieser Token-Generator nichts "festes" sein soll, welches nur für LQFB verwendet wird und nichts anderes. Die Idee dahinter ist ja, dass man damit immer zeitbegrenzt gültige Tokens an alle Piraten versenden kann, die sie dann für verschiedene Aktionen verwenden können (z.B. auch 50 Stimmzettel mit einem Token ausfüllen)
• inwieweit Du sicherstellst, das diese Keypairs nicht zweckentfremdet werden können
  • Es gibt hier ein ganz klares Angriffsszenario: Beim User selbst. Die Übermittlung der Keypairs muss als "sicher" betrachtet werden
    • Hier meinte ich eher, was miut den Tausenden private keys passiert, die dann "sinnlos" rumliegen. Und, neu: wie eine "Wiederverwendung" ausgeschlossen wird und wie der Abgleich gg. die schnell wachsende Revocation list (gilt für PGP und CA) skaliert.
      • Ist es nicht im Prinzip egal, ob diese PGP-Keys auch für andere Dinge verwendet werden oder nicht? Ich sehe hier keinen Grund, warum man hier eine "Zweckentfremdung" verhindern soll.
• welcher (Zeit-)Aufwand pro Abstimmvorgang für einen Nutzer entsteht
  • Das kommt drauf an, welchen Client er zur Abstimmung benutzt. Das Ganze lässt sich weitgehend automatisieren
    • Eine Zahl als Schätzung? 5min? 1min? 10sek? Wie verhält sich bei sinkender unterer Schranke das notwendige Vertrauen?
      • Ich denke, man kann einen Client programmieren, der einmal startet und dafür 10 Sekunden benötigt; dann kann man einzelne Stimmzettel genauso schnell ausfüllen wie in LF (also insgesamt ist das dann wieder abhängig von den verschiedenen Initiativen und wie intensiv man die sich vor dem Abstimmen noch mal durchlesen will). Ich denk mal, man kann einen Stimmzettel in unter 5 Sekunden ausfüllen, wenn man denn will.
• inwieweit das Fehlen Deines "optionalen Datenschutzfeatures" den Schutz durch die Clearingstelle nicht aushebelt
• inwieweit ein solches System "DAU-kompatibel" (User ohne GPG-Knowhow) sein kann und welchen Komponenten dann vertraut werden muss
  • Kommt drauf an, wie gut der Installer ist. Das System geht von einem lokalen Client aus, von dem auch mehrere verschiedene existieren können; implementiert von unabhängigen Stellen. Man kann auch einen "Klicken Sie auf Weiter"-Installer implementieren
    • Punkt Vertrauen? Welche Komponenten sind dann nicht mehr überprüfbar, da vor dem Anwender versteckt?
      • Man muss dem System genauso vertrauen wie man dem Hersteller seines Rechners und der Software vertrauen muss. Da das verwendete Protokoll offen ist und der Client am Ende eine XML-Datei an den Server schickt, kann sich auch jeder selbst seinen eigenen Client programmieren.
• wie Du sicherstellst das Überschreiben von vorhandenen Stimmen die "richtigen" Stimmen überschrieben werden
  • Indem jeder "Stimmzettel" zusätzlich noch über die Information des Abstimmungs-Codes und des Zufalls-Strings verfügt. Er muss GPG-signiert sein. Prinzipiell hat der Admin hier natürlich eine Chance, das System anzugreifen: Er kann als BOFH spätere Stimmänderungen des Nutzers nicht berücksichtigen
• wie man (wie behauptet) die Stimmen anderer überprüfen kann
  • Es werden alle gültigen Tokens (Abstimm-ID + Zufallsstring) zusammen mit dem gültigen Public Key veröffentlicht (beim Token-Generator-System). Der Stimmakkumulator veröffentlicht am Ende alle unterschriebenen Stimmzettel. Ansonsten weiß ich jetzt nicht, was Du mit "Stimmen anderer überprüfen" meinst. Das hier vorgestellte Abstimmungssystem ist ja anonym. Man kann natürlich auch seine Tokens + Private Keys nach jeder Abstimmung veröffentlichen; dann ist das ganze genauso transparent wie Liquid Feedback selbst. Es steckt jedoch kein Zwang dahinter
    • Die Behauptung "Stimmen anderer" überprüfen zu können kam von Dir :-)
• welcher Hardware- und Administrationsaufwand anfällt
  • Das müsste getestet werden.
• wie sichergestellt ist das Admins nicht manipulieren können
  • Es gibt eine Stelle, wo Admins manipulieren können: Im Token-Generator (da kann man die Software manipulieren, so dass sie die Keys "abgreifen" können

Danke Dir. --tarzun 20:14, 24. Aug. 2010 (CEST)

Hab noch nicht alles beantwortet; nur mal so auf die Schnelle --Haibaer 01:03, 25. Aug. 2010 (CEST)