Diskuse s wikipedistou:Beren/CsArbComVote

Administrátoři

Myslím, že když zvolíme administrátory voleb, mohou si mechanismus předávání klíčů určit oni. Já navrhuju dvojici Luděk a Mormegil. Nejsou na seznamu kandidátů a už jsme jim vyjádřili plnou důvěru při volbě sysopů. Nevím ale, jestli oni souhlasí. --Egg ✉ 16:00, 24. 11. 2005 (UTC)

GPG

Extense funguje (dá se naživo vyzkoušet na http://iuridictum.pecina.cz/phase3/index.php) a hlasování se s ní určité dá provést, jen - musím si rýpnout - je na ní patrné, že autoři tak docela neporozuměli tomu, jak funguje asymetrická krypografie vůbec a program gpg zvlášť.

1. Řádek s voláním gpg pro zašifrování hlasu neobsahuje parametr -u, takže gpg se pokusí zprávu podepsat prvním klíčem, který najde v secringu (nebo default kličem, je-li určen), a pokud tento klíč má nenulovou passphrase, ohlásí chybu. Tzn. fungovat bude víceméně jen tehdy, pokud uživatel, pod kterým běží Apache, gpg pro nic jiného nepoužívá.
2. Vyhodnocovat výsledek skriptem spustitelným z příkazového řádku je nepochopitelné rozhodnutí: minimálně proto, že se musí komunita spolehnout na poctivost toho, kdo skript spouští. O dalších problémech s klíči pomlčím.

Rozumné řešení by bylo, kdyby se použil jediný klíč serveru, ke kterému by nikdo kromě skriptu (tzn. Apache) neměl přístup. Veřejným klíčem by se kódovaly hlasy, které by se ukládaly do logu (jako se to děje nyní), a dekódovaly by se soukromým klíčem jedině do podoby souhrnných výsledků, které by byly dostupné každému po skončení hlasování, eventuálně do výpisu - účelnost škrtání hlasů pokládám ale za krajně spornou. Tak by bylo zajištěno, že se nikdo, kdo nemá přístup na server, nedozví obsah jednotlivých hlasů, a naopak každý - nikoli jen správce - bude mít přístup k authoritativním výsledkům. Naopak kdo přístup na server má, se průběh dozví vždy.

Myšlenka použít dvou klíčových párů je podle mě od počátku chybná - nebo jsem něco nepochopil?

Kolegovi Berenovi samozřejmě patří velký dík, že skript počeštil. --Tompecina 22:32, 26. 11. 2005 (UTC)

Rozšíření počítá s tím, že uživatel, pod kterým běží Apache, má jen jeden tajný klíč. Myslím, že to je vcelku rozumný předpoklad, protože to je obvykle účet speciálně pro webserver, u kterého se interaktivní přístup nepředpokládá, a tudíž ani nemá smysl mít jej zajištěný heslem.

Zajistit dekódovaní hlasů jedině do podoby souhrnných výsledků Vámi popsaným způsobem by vyžadovalo, aby tajný klíč k hlasům volně ležel na webserveru. Obávám se, že takové řešení by tajnosti voleb neprospělo.

Myšlenka použití dvou klíčových párů zajišťuje, že pokud útočník během voleb nezmění zpracovávací skripty, nemůže z dat uložených na webserveru a v databázi žádným způsobem zjistit, kdo jak hlasoval. Stejně tak to nemůže zjistit administrátor voleb, za předpokladu, že nemá přístup k holým tabulkám v databázi. Neboli:

• jeden klíčový pár slouží k zašifrování hlasů tak, aby nikdo, kdo si je přečte přímo z databáze, nemohl narušit tajnost voleb
• druhý klíčový pár slouží k podepisování hlasů na webserveru, a tím zajišťuje, že hlasy v databázi pochází opravdu z něj

Je pravda, že druhý pár má smysl pouze v případě, že někdo chce podvrhnout hlasy v databázi, ale nemá přístup k tajnému klíči na webserveru. To je značně nepravděpodobná varianta, takže jeho přínos k bezpečnosti voleb je nízký. Nicméně ničemu neškodí. --che 15:53, 27. 11. 2005 (UTC)

(PS) Celkově: celý smysl použití GPG a boardvote je v tom, aby se ani člověk s přístupem na server nedozvěděl průběh voleb. Pokud by nám toto nevadilo, nemusíme hlasy vůbec šifrovat a stačí je prostě na webu nevypisovat.

Co do možnosti škrtání hlasů: je to asi jediná obrana proti ovlivňování voleb sockpuppety. --che 16:04, 27. 11. 2005 (UTC)

K tomu podrobněji:

Rozšíření počítá s tím, že uživatel, pod kterým běží Apache, má jen jeden tajný klíč. Myslím, že to je vcelku rozumný předpoklad, protože to je obvykle účet speciálně pro webserver, u kterého se interaktivní přístup nepředpokládá, a tudíž ani nemá smysl mít jej zajištěný heslem.

Nevím, že by servery měly běžně vygenerovaný GPG klíč, normálně si vystačí s SSL klíčem. U mě bylo nutno parametr -u doplnit, jinak se gpg pokusil o podpis mým osobním klíčem, který passphrase samozřejmě má, takže skript zhavaroval. --(Tompecina)

Nemají, je potřeba jej vytvořit, jak popisuje přislušná kapitola návodu. Z bezpečnostního hlediska nelze provozování webserveru pod účtem živého uživatele doporučit, proto lze předpokládat, že na serverech Wikimedia to tak nastaveno není. Je nicméně fakt, že určení klíče nemůže škodit a v tomto podle mého názoru atypickém případě pomůže. --che 21:00, 27. 11. 2005 (UTC)

httpd pod živým uživatelem neběží, nejsem sebevrah. Ale odkaz na .gnupg jsem na živého uživatele namířil, netuše zlého. --Tompecina 22:54, 27. 11. 2005 (UTC)

Zajistit dekódovaní hlasů jedině do podoby souhrnných výsledků Vámi popsaným způsobem by vyžadovalo, aby tajný klíč k hlasům volně ležel na webserveru. Obávám se, že takové řešení by tajnosti voleb neprospělo.

Secring uživatele csarbcomvote musí být uživateli, pod kterým běží httpd (např. apache), přístupný na read, jinak by se nevytvořily šifrované hlasovací záznamy. Tudíž tajný klíč k hlasům na webserveru leží. --(Tompecina)

Nikoliv; k zašifrování hlasů stačí klíč veřejný, neboť GPG používá asymetrické šifry. --che 21:00, 27. 11. 2005 (UTC)

Myšlenka použití dvou klíčových párů zajišťuje, že pokud útočník během voleb nezmění zpracovávací skripty, nemůže z dat uložených na webserveru a v databázi žádným způsobem zjistit, kdo jak hlasoval.

Útočník, který má write přístup do kteréhokoli adresáře přístupného Apachi, to zjistí velmi snadno, protože si napíše skript, který mu data dešifruje. Použitý postup chrání toliko proti útočníkům, kteří se dostanou k dumpu databáse - ovšem ani ti nejsou bez šance, protože záznam je málo (a chybně) osolen. --(Tompecina)

Data nelze snadno dešifrovat, neboť na webserveru tajný klíč nebude. Útočník by musel buď zkoušet veškeré kombinace hlasů a osolení (které by, pravda, mohlo být větší), nebo přepsat skripty na cswiki tak, aby mu hlasy nějak posílaly před zašifrováním. Což je ovšem u PHP skriptu celkem snadno odhalitelné. --che 21:00, 27. 11. 2005 (UTC)

Je pravda, že druhý pár má smysl pouze v případě, že někdo chce podvrhnout hlasy v databázi, ale nemá přístup k tajnému klíči na webserveru. To je značně nepravděpodobná varianta, takže jeho přínos k bezpečnosti voleb je nízký. Nicméně ničemu neškodí.

Škodí do jisté míry věrohodnosti, protože výsledky jsou takto zpřístupněny jen správcům voleb, resp. osobám, které mají přístup k tajnému správcovskému klíči. Nejsem paranoik, ale nedostatek to objektivně je. --(Tompecina)

To ano. Na druhou stranu to umožňuje tajnost volby. --che 21:00, 27. 11. 2005 (UTC)

Podvrhnutí hlasů by stejně dobře zabránilo, kdyby se zašifrované hlasy podepsaly klíčem csarbcomvote. Takto je to drbání levou rukou za pravým uchem. --(Tompecina)

Problém s podepisováním hlasů klíčem csarbcom vote je právě ten, že by vyžadovalo nezdravou přítomnost tajného klíče na webserveru. Potom, jak už jsem psal, se hlasy klidně mohou ukládat do databáze v plaintextu, neboť je může snadno přečíst kdokoli s přístupem na webserver. --che 21:00, 27. 11. 2005 (UTC)

Celkově: celý smysl použití GPG a boardvote je v tom, aby se ani člověk s přístupem na server nedozvěděl průběh voleb. Pokud by nám toto nevadilo, nemusíme hlasy vůbec šifrovat a stačí je prostě na webu nevypisovat.

Jak jsem vysvětlil, před útočníkem oprávněným modifikovat skripty se průběh hlasování neutají. Ten může leccos, např. overloadovat funkci, kterou se gpg volá. Další slabinou jsou ty temporary soubory - takové věci se, pokud to lze, řeší echem s rourou.

Pokud by nevadili sockpuppeti (a kvalifikovaných k hlasování bude zpravidla zanedbatelný počet), stačí prostě hlasy přičítat k čítačům a průběh do databáse nelogovat. Pokud vadí, je potřeba hlasy zašifrovat. --Tompecina 20:09, 27. 11. 2005 (UTC)

Jak už jsem ukázal, k narušení tajnosti voleb při současném schématu nestačí modifikovat jakýkoli skript, ale je třeba modifikovat právě skript ošetřující volby. Mám za to, že něco takového je ohlídatelné snadněji než zamezení čtecích přístupu na webserver.

Jestli suckpuppeti vadí nebo nevadí je otázka, je ale třeba vzít v úvahu, že prosté přičítání hlasů by také změnožnilo jejich dodatečnou změnu v případě omylu hlasujícího. --che 21:00, 27. 11. 2005 (UTC)

Jak už jsem ukázal, k narušení tajnosti voleb při současném schématu nestačí modifikovat jakýkoli skript, ale je třeba modifikovat právě skript ošetřující volby.

To bohužel ne. Můžete si do skriptu includovat LocalSettings.php, čímž získáte heslo k databási (nebo si ho prostě přečíst), a pak zavoláte na jednotlivé hlasy "gpg --decrypt". Výstupem jsou hlasy v plaintextu. Věřte mi, vyzkoušeno :-)

Záměr byl, jaký píšete, ale realisace nevyšla.

S měněním hlasů máte pravdu, jen je otázka, zda je taková funkčnost opravdu potřebná. --Tompecina 21:33, 27. 11. 2005 (UTC)

Pokud je útočník schopen modifikovat hlasovací skript na serveru v průběhu voleb a nikdo na to ani nepřijde, pak proti takovému selhání bezpečnosti sebegeniálnější hlasovací algoritmus nepomůže. Algorimus se snaží spíše ochránit před jakýmkoliv útočníkem s právem čtení.

Nevěřím, že by na serveru, který s tajným klíčem od administrátorů voleb vůbec nepřijde do styku, šlo rozšifrovat data jednou zašifrovaná veřejným klíčem. Domnívám se, že se Vám ve Vašem testovacím prostředí nepodařilo dodržet mechanismus distribuce klíčů a máte na serveru dostupný tajný klíč z páru "csarbcomvote".

Abych jen neoponoval, všiml jsem si a cením si Vaší oprávněné kritiky velikosti osolení. Svou chybu napravím. --Beren 22:07, 27. 11. 2005 (UTC)

Domnívám se, že se Vám ve Vašem testovacím prostředí nepodařilo dodržet mechanismus distribuce klíčů a máte na serveru dostupný tajný klíč z páru "csarbcomvote".

Ano, a kde jinde by měl být? Kdyby si ho vygeneroval správce a na webserver exportoval pouze pubkey, mohl by si hlasy přečíst v teple domácího serveru, a to jistě úmysl tvůrců nebyl.

Musel byste pro něj zřídit zvláštní server, odlišný od webserveru, a zajistit, že správce tohoto serveru bude tak čestný a tajný klíč nikomu neposkytne. Bylo snad toto záměrem? Jsem poněkud zmaten... --Tompecina 22:34, 27. 11. 2005 (UTC)

Tajný klíč má být u administrátorů voleb, a to právě proto, aby se oddělily osoby s přístupem na webserver a osoby schopné rozšifrovat hlasy. Ty na to pak nepotřebují žádný webserver, stačí jim gpg a z příkazové řádky spuštěné PHP. --che 22:41, 27. 11. 2005 (UTC)

Už to vidím - bylo to tak myšleno. Pak je ovšem situace horší, než jsem si myslel. Kterýkoli správce voleb bude mít možnost seznámit se s jednotlivými hlasy a volba bude všechno jiné, jen ne tajná. Tato varianta mě skutečně nenapadla, měl jsem za to, že jde o nevhodnou formulaci a klíč pro csarbcomvote se ve skutečnosti bude generovat na webserveru. --Tompecina 22:44, 27. 11. 2005 (UTC)

Proč myslíte, že volba nebude tajná. Záznam se zašifrovanými hlasy poskytnutý všem po skončení voleb neobsahuje žádné informace o tom, kdo jednotlivé hlasy vložil (dokonce i pořadí je záměrně náhodně zpřeházeno). Takže volby zůstávají tajné i pro administrátory voleb, kteří pomocí tally.php spočítají výsledky a zveřejní je. --Beren 22:50, 27. 11. 2005 (UTC)

O záznamu, který se generuje k vyhodnocení, jsem nemluvil, měl jsem na mysli, že si správci přečtou hlasy v dumpu databáse. Pokud vím, dumpy všech databásí se archivují a jsou volně přístupné. Jste si jist, že tato databáse bude z archivace vyňata, a to trvale? --Tompecina 23:01, 27. 11. 2005 (UTC)

Dumpy všech databází rozhodně veřejně přístupné nejsou, jsou přístupné pouze nesmazané články a jejich historie. Nepředpokládám, že by byly zveřejněny i dumpy hlasovací databáze (ostatně nejsou zveřejněny ani databáze uživatelů). --Petr.adamek 23:03, 27. 11. 2005 (UTC)

Dobře, věřím Vám, vyjděme z toho, že jiné než neshufflované hlasy ani správci nedostanou. Pak tedy můžeme porovnat výhody a nevýhody metody s jedním nebo dvěma páry klíčů:

Dva páry:
+ ke zjištění průběhu hlasování - pokud se vylepší osolení - nestačí ani samotný dump databáse, ani správcovský soukromý klíč, pouze kombinace obojího
- hlasování není tajné pro útočníka, který má přístup ke skriptům
- výsledky hlasování mohou zobrazit pouze správci
- nikdo jiný nemůže zkontrolovat, zda jsou výsledky takové, jaký správci presentují

Jeden pár:
+ ke zjištění průběhu hlasování nestačí ani dump databáse, ani soukromý klíč serveru, pouze kombinace obojího
- hlasování není tajné pro útočníka, který má přístup ke skriptům
+ výsledky hlasování může zobrazit kdokoli

To je nepopiratelné vítězství pro methodu jednoho klíče. --Tompecina 23:15, 27. 11. 2005 (UTC)

Dva další faktory:

• v případě nedůvěry správcům je možné přizvat dalšího člověka,který dostane tajný klíč a výsledky ověří, což podle mého názoru značně omezuje dopad dvou nevýhod metody se dvěma klíči, ale především
• je-li jeden použit jeden pár klíčů, stačí ke zjištění průběhu hlasování read-only přístup na server, kterým může útočník najednou z jednoho stroje stáhnout jak dump databáze, tak i tajný klíč, kterých jsou data zašifrována. Tuto podle mého názoru podstatnou nevýhodu metoda dvou klíčů nemá.

--che 23:33, 27. 11. 2005 (UTC)

Secring je world-invisible, takže read přístup nestačí, potřebujete write na skripty. A kdo je má, může provést úspěšný útok tak jako tak. Tím netvrdím, že Váš argument nemá svou váhu, jen mi nepřijde dostatečně silný. --Tompecina 00:25, 28. 11. 2005 (UTC)

V tom máte asi pravdu, ale pořád mám za to, že při podrvržení PHP skriptů je daleko vyšší pravděpodobnost odhalení a nápravy než při pouhém stažení citlivých dat (a klíče), protože pokud má upravený skript na serveru fungovat, musí být vidět. --che 00:44, 28. 11. 2005 (UTC)

Připouštím, že máte částečně pravdu: pro dobytí jednopárového systému stačí umístit na server skript na několik sekund, kdežto u dvoupárového musí být změněný skript (backdoor) přítomen po celou dobu hlasování. --Tompecina 01:13, 28. 11. 2005 (UTC)

Ve světle zjištění, že podpis klíčem cswiki způsobí kompromitaci voleb, je třeba předchozí poznámku modifikovat - není už řeč o dvoupárovém a jednopárovém modelu, ale o modelu uložení soukromého klíče na webserveru nebo u správců ("veřejný" a "soukromý" model). Mezitím jsem odhalil další potenciální slabinu, a sice to, že zašifrovaný záznam obsahuje název dočasného souboru. Protože neznám algorithmus, kterým se tyto názvy generují, nemám jistotu, že znalost těchto názvů nemůže vést ke zjištění pořadí, ve kterém byly záznamy šifrovány. To je další minus pro soukromý model. --Tompecina 08:39, 28. 11. 2005 (UTC)

Nežádoucí informace v datech

Vsuvka z jiného soudku: Uzavřel jsem si hlasování a zjistil, že z dumpu lze zjistit, kdy byl který hlas podepsán. Tím mohu hlas spojit s hlasujícím. Nebo ne? --Tompecina 00:22, 28. 11. 2005 (UTC)

Ano. To je dosti podstatná vada. Řešení, které mne v tuto chvíli napadá, je prostě hlasy webserverem nepodepisovat, protože to stejně nepřináší žádnou dodatečnou bezpečnost – pokud je útočník schopen podvrhnout hlasy na webserveru, nebude pro něj žádný problém je klíčem na webserveru také podepsat. --che 00:44, 28. 11. 2005 (UTC)

Vyzkoušel jsem to a funguje, timestamp zašifrování neprozradí ani gpg -vv --decrypt. Jestli tam tento timestamp ale opravdu není, budeme muset najít v dokumentaci, popř. ve zdrojácích gpg. --Tompecina 01:05, 28. 11. 2005 (UTC)

Je tam - v sekci "literal data packet". Takže jsme s tajností voleb jaksi v troubě. --Tompecina 08:57, 28. 11. 2005 (UTC)

Zde je to celé:

[tompecina@pecina iuridictum.pecina.cz]$ gpg -vv --decrypt t6.asc
gpg: armor: BEGIN PGP MESSAGE
gpg: armor header: Version: GnuPG v1.4.1 (GNU/Linux)
:pubkey enc packet: version 3, algo 16, keyid A784CE6DC3C2E648
        data: [2046 bits]
        data: [2047 bits]
gpg: public key is C3C2E648
gpg: using subkey C3C2E648 instead of primary key 72FFE296
gpg: public key encrypted data: good DEK
:encrypted data packet:
        length: 194
        mdc_method: 2
gpg: using subkey C3C2E648 instead of primary key 72FFE296
gpg: encrypted with 2048-bit ELG-E key, ID C3C2E648, created 2005-11-26
      "csarbcomvote <iuridictum@pecina.cz>"
gpg: AES256 encrypted data
:literal data packet:
        mode b (62), created 1133166710, name="gpg_0oyyU2",
        raw data: 135 bytes
gpg: original file name='gpg_0oyyU2'
14867
Hlasoval jsem pro: Čechodav
Hlasoval jsem proti: Puňťa
Zdržel jsem se: Bobík
:mdc packet: length=20
gpg: decryption okay

Pokusil jsem se timestamp z šifrovaných dat odstranit zkuste prosím novou verzi na [1]. Nemám nainstalovanou vlastní MediaWiki, takže prosím o shovívavost ;) --che 22:54, 28. 11. 2005 (UTC)

Já shovívavý jsem, ale php je nějak ve špatné náladě. Toto Vám vzkazuje přes error_log: [client 127.0.0.1] PHP Parse error: parse error, unexpected T_SL in /var/www/html/iuridictum.pecina.cz/phase3/extensions/CsArbComVote/CsArbComVote.php on line 369, referer: http://iuridictum.pecina.cz/phase3/index.php/Speci%C3%A1ln%C3%AD:Csarbcomvote. Ale vydržte, na poruche sa pracuje, jak říkávali ve federální televisi... --Tompecina 07:50, 29. 11. 2005 (UTC)

Ano, po mírných úpravách se zdá, že to funguje:

:literal data packet:
        mode ? (0), created 0, name="",
        raw data: 135 bytes
gpg: original file name=''

Moc bezpečně bych se ale při takovém hlasování necítil. --Tompecina 08:28, 29. 11. 2005 (UTC)

Za mírné úpravy velice děkuji. Můžete prosím někam vystavit novou verzi? (Hádám-li správně, že Vaše výhrady k bezpečnosti se vztahují k celému postupu, pak je můžeme probrat u oddlílu s další anternativou, kterou se pro tento účel chystám založit.) --che 13:48, 29. 11. 2005 (UTC)

To ani nestojí za posílání, stačilo přemístit funkci make_gpg_literal na nejvyšší úroveň. A pak samozřejmě zrušit -s ve volání gpg, ale to už máme vyřešeno. --Tompecina 15:01, 29. 11. 2005 (UTC)

Zásadní dotaz

Jakožto amatér ve světě počítačů se nehodlám zabývat technickými problémy s nějakými klíči. Otázka zní: Podle pravidla o arbcomu hlasují pouze ti, co mají více než 50 příspěvků v článcích k začátku voleb. Je v navrhovaném systému možno zajistit odfiltrování hlasů, které tyto podmínky nesplňují? Cinik 06:43, 28. 11. 2005 (UTC)

Přispěvatele, kteří podmínku nesplňují, systém k hlasování nepustí. --Beren 06:45, 28. 11. 2005 (UTC)

OK... Snad jen: Jak a odkud ověří počet příspěvků? Cinik 07:12, 28. 11. 2005 (UTC)

Protože jde o rozšíření, které se musí umístit přímo do MediaWiki české Wikipedie, tak by samozřejmě sdílelo přístup přímo k její živé databázi. --Beren 07:17, 28. 11. 2005 (UTC)

Ve skutečnosti je i tato funkčnost implementována chybně, protože se kontroluje počet editací nikoli k začátku voleb, ale až v okamžiku hlasování. --Tompecina 09:37, 28. 11. 2005 (UTC)

Jak jste na to přišel? Mě se při testování nepodařilo přimět k uznání hlasování jednou odmítnutého uživatele a navíc řádek: $sql = "SELECT COUNT(*) as n FROM $revision, $page WHERE rev_timestamp<=$date AND rev_user=$id AND rev_page=page_id AND page_namespace = 0";, kde $date je datum počátku voleb (proměnná $wgCsArbComVoteCountDate), vypadá naprosto v pořádku. --Beren 09:54, 28. 11. 2005 (UTC)

Ano, máte pravdu. Nevšiml jsem si toho přiřazení $date, měl jsem za to, že se používá globální. --Tompecina 10:10, 28. 11. 2005 (UTC)

Návrhy řešení

Varianta A (Tompecina)

Veřejná volba.

Výhody:
+ žádná další práce ani nutnost komunikace se zaneprázděnnými developery
+ možnost vysvětlit důvody jednotlivých hlasů

Nevýhody:
- stádnost hlasování
- strach z pomsty kandidátů
- nebezpečí apriorní podjatosti takto zvolených členů ArbComu vůči jednotlivým hlasujícím

Uskutečnitelnost: okamžitá

Varianta B (Tompecina)

Pro šifrování se nepoužije dočasný soubor, ale jeden trvalý soubor, který se bude bude stále přepisovat novými daty (echo s rourou nestačí, protože timestamp se generuje i v takovém případě).

Výhody:
+ minimální úprava existujících skriptů

Neýhody:
- PGP není k utajení času, kdy byl ciphertext vytvořen, určeno a nezaručuje je, takže nemáme jistotu, že to nelze z jeho obsahu zjistit ještě jinak než volbou -vv
- neřeší problém, že výsledky hlasování se dozvědí jen správci a ostatní jim musejí věřit

PS: Varianta B padá, protože - jak jsem právě experimentálně ověřil - "created" se nevztahuje ke zdrojovému souboru, ale k vytvoření ciphertextu. Budu ještě hledat volbu, jak tomu zabránit (to by byla Varianta D), ale dost pochybuji... --Tompecina 12:53, 28. 11. 2005 (UTC)

Varianta C (Tompecina)

Varianta s jedním klíčovým párem na webserveru, který se po skončení hlasování spolu s databásí výsledků vymaže (plus přisolení).

Výhody:
+ veřejnost a transparentnost výsledků hlasování
+ bezpečnost před správci
+ odolnosti proti útoku hrubou silou (ciphertext za normálních okolností vůbec neopustí server)

Nevýhody:
- nutnost většího zásahu do skriptů
- risiko, že developeři skript, který neznají a který se bude významně lišit od původního, pro nadaci, nepřipustí
- k narušení tajnosti stačí jeden útok na webserver a přečtení dat; tím je bezpečnost v podstatě ekvivalentní variantě E

Uskutečnitelnost: neznámá

Přece jen o něco vyšší, protože útočník musí skripty upravit - k Apachově privátnímu klíči se jinak nedostane. Tvrdím ovšem, že před útočníkem, který toto dokáže, je bezbranný každý systém - uvědomte si, že nikdo ze správců ani ostatních uživatelů cs.wiki nemá možnost kontrolovat, jestli nebyly skripty změněny. --Tompecina 16:07, 28. 11. 2005 (UTC)

Nesmyslné použití asymetrické kryptografie jako náhrady symetrické kryptografie. --Wikimol 17:03, 28. 11. 2005 (UTC)

Tak tedy symetricky, proč ne? Ale šifrování záznamu v databási svůj účel má, čímž je tato varianta lepší než E. --Tompecina 19:21, 28. 11. 2005 (UTC)

Varianta D (Tompecina)

Bude se šifrovat jinými prostředky než voláním gpg, např. libgcryptem nebo mcryptem.

Výhody:
+ snesitelná úprava existujících skriptů

Nevýhody:
- neřeší problém, že výsledky hlasování se dozvědí jen správci a ostatní jim musejí věřit
- developeři nemusejí být touto myšlenkou nadšeni

Uskutečnitelnost: neznámá

Varianta E (Che)

Hlasy se prostě uloží v databázi, skripty pustí ven na web jen součty.

Výhody:
+ jednoduchost
+ bezpečné před správci

Nevýhody:
- k narušení tajnosti stačí jeden útok na webserver
- k tomu stačí přístup do databáse, popř. k dumpu --Tompecina 16:04, 28. 11. 2005 (UTC)

Uskutečnitelnost: neznámá

Varianta F (Wikimol)

Hlasy se uloží v tabulce A, přiřazení hlasy - hlasující v tabulce B, hlasující C. Na konci se zveřejní A a C a tabulka B se smaže. Rozdílem oproti E je ověřitelnost hlasování.
Bezpečnost lze mírně zvýšit symetrickým šifrováním tabulky B s klíčem uloženým na serveru, čímž se stane ekvivalentní nebo lepší než u varianty C.

Uskutečnitelnost: neznámá

Při INSERTU se záznamy do databáse ukládají postupně, takže z dumpu zjistíte, kdo jak hlasoval. Je to spíš jen pracnější varianta E. --Tompecina 17:16, 28. 11. 2005 (UTC)

Co to znamená "postupně"? V průběhu hlasování je dump hlasů tajný, takže sledovat rozdíly nemůžete. Hlasy se ukládají s (podle předpokladu tajnou) informací z tabulky B jako primárním klíčem, takže z fyzického uložení v souboru se při vhodném formátu tabulky nedozvíte nic.

Jak jsem napsal, buď to lze považovat za variantu E s ověřitelnými výsledky, nebo za variantu C bez nesmyslného použití asymetrické kryptografie. --Wikimol 17:51, 28. 11. 2005 (UTC)

Postupně znamená minimálně to, že kdo má read přístup k DB, zjistí hlasy tím, že bude sledovat jejich přibývání. Asymetrický algorithmus nemá proti symetrickému zvláštní výhody, ale nevidím ani nevýhody. Zabezpečení je dáno tím, že developeři převezmou skripty v publikované podobě, takže algorithmus bude ověřitelný. --Tompecina 18:17, 28. 11. 2005 (UTC)

Toto je IMHO vhodný způsob. Nemyslím, že je rozumně za daných podmínek dosažitelná úplná bezpečnost a utajení i před zákeřnými crackery a vývojáři s root kontem na serverech Wikipedie... Ověřitelnost hlasování je však zásadní featura, která zajišťuje, že ani tito nebudou snadno schopni hlasování ovlivnit. Co se mě týče, nemám potřebu utajovat svoje hlasování před Timem Starlingem, pro mě je u tajného hlasování podstatné jen to, že běžný uživatel nebude vědět, jak jsem hlasoval (ale spokojil bych se klidně i s veřejným hlasováním, BTW). --Mormegil ✉ 16:49, 29. 11. 2005 (UTC)

Také se nedomnívám, že jde o absolutní bezpečnost, která asi neexistuje - na tom ztroskotalo již více finančních institutů, pojišťoven atd. Jde o to: během či v okamžiku hlasování se chci osvobodit od tlaku , který vzniká tím, s kým jsem kamarác a s kým ne, čili chci skutečně volit podle mého gusta. Že tento hlas zcela utajit nemohu je jasné, jde jen o to, kdo ho rozluští. Toto říkám nejen jako někdo, kdo chce hlasovat, ale jako někdo, kdo zde kandidoval. Stejně jako Mormegil bych důvěru k možným dministrátorům měl, ať to uz bude Tim S. nebo někdo s obdobnými vlastnostmi, já navrhl angažovat minimálně nějakého stewarda či stewardku z mezinárodní wikipeide. -jkb- ✉ 17:45, 29. 11. 2005 (UTC)

Jasně, s tím lze naprosto souhlasit. Momentální situace je ale taková, že zdánlivě jednoduché E a jeho bezpečnější alternativy C nebo F jsou mnohem pracnější než např. H, které máme. Pokud jde o věrohodnost správců hlasování, mohu jim osobně věřit, ale to neznamená, že k tomu mohu legitimně nutit kohokoli jiného - námitka potenciálního zkreslení voleb správci je významná, a i správci když někomu dají svůj klíč, nedají ho jistě všem - to by žádný nemuseli mít. --Tompecina 22:16, 29. 11. 2005 (UTC)

Varianta G (Tompecina)

Napíše se to celé pořádně, a ne nutně jako extense, ale jako feature MediaWiki.

Výhody:
+ výsledek bude použitelný pro všechna další tajná hlasování, a to i pro ostatní komunity
+ žádné problémy s developery
+ maximální úroveň bezpečnosti, kterou budeme schopni vymyslet a implementovat

Nevýhody:
- poměrně dost práce

Uskutečnitelnost: „nestane-li se něco mimořádného, bude za několik dní (možná už po víkendu, ne-li dřív) připravená k testování“ (Tompecina, 1.12.)

Vy rýpale :-) Zatím nic mimořádného nenastalo a vše jde hladce. --Tompecina 11:11, 2. 12. 2005 (UTC)

K této variantě mám něco rozpracováno, s použitím standardních mechanismů MediaWiki a speciálních šablon. --Tompecina 14:53, 29. 11. 2005 (UTC)

Popsáno je to zde: Wikipedista:Tompecina/Tajné_hlasování. --Tompecina 23:12, 29. 11. 2005 (UTC)

Varianta H (che)

CsArbComVote, se dvěma klíčovými páry. Hlasy jsou šifrovány tajným klíčem správců voleb, které se vůbec nenacházejí na serveru. Server podepisuje jen hlasy, které zobrazuje uživatelům, aby bylo možné posoudit jejich případné stížnosti.

Výhody:
+ prakticky hotové
+ k narušení bezpečnosti je třeba buď vyměnit skripty na serveru, nebo zároveň získat přístup k databázi a tajnému klíči správců voleb

Nevýhody:
- je třeba důvěřovat správcům voleb, že hlasy správně sečtou (ti ale v případě pochybností mohou poskytnout svůj klíč další osobě, která může výsledek ověřit)
- stále nemáme exaktně prokázáno, že se timestamp nedá i z očesaného ciphertextu určit --Tompecina 14:51, 29. 11. 2005 (UTC)

Uskutečnitelnost: vyžaduje dvě úpravy současné Berenovy verze, což není na dlouho, bude-li zájem

Σ

Doplnil jsem k jednotlivým variantám pole pro jejich uskutečnostelnost, protože si myslím, že by zase nebylo hezké nechat Víta Zvánovce čekat do jara. Já osobně bych byl pro použití csarbcomvote (H), protože poskytuje velmi slušnou úroveň bezpečnosti, je prakticky hotové, a už prošlo mnoha připomínkami. Jaké jsou vaše názory? --che 20:49, 1. 12. 2005 (UTC)

Na G celkem intensivně pracuji, nestane-li se něco mimořádného, bude za několik dní (možná už po víkendu, ne-li dřív) připravená k testování. Její velkou výhodou je obecnost, není to nic ad hoc, co by se použilo jednou, ale dá se pomocí ní bez dalšího programování hlasovat kdykoli o jakémkoli návrhu nebo souboru návrhů. H je silně kompromisní varianta (její bezpečnosti, jak jsem napsal, nevěřím), ale z ostatních zřejmě nejlepší. --Tompecina 23:16, 1. 12. 2005 (UTC)

Otázkou je, k čemu univerzální systém, když žádná další tajná hlasování nikdo neplánuje. I správci se volí veřejně... Cinik 06:38, 2. 12. 2005 (UTC)

Kdyby pro nic jiného, tak kvůli doplňovacím volbám do ArbComu. --Tompecina 07:01, 2. 12. 2005 (UTC)

Na ty není potřeba univerzální systém, stačí hlasovadlo specializované pro volby do ArbComu. Jinak co do bezpečnosti mám dojem, že variantě H vytýkáte nedokonalosti, na jejichž řešení varianta G zcela rezignuje – hlasy jsou u ní uloženy na serveru, který je i dešifruje. Z toho plyne, že kdo má přístup na server, může se dostat ke klíči a tudíž i k hlasům. Dále mám pocit, že přesvědčit vývojáře MediaWiki k nainstalování jednoho rozšíření pro cswiki bude snadnější a půjde to prosadit rychleji než patchování celé aplikace. --che 15:34, 2. 12. 2005 (UTC)

To jsou správné poznámky. Nejprve ke druhé: zda hlasování implementovat jako feature nebo extensi, je nedůležité - obě varianty jsou technicky řešitelné, přejít od jednoho ke druhému není nijak zvlášť obtížně. Určitě ale budou developeři raději implementovat universální než jednorázový systém, ať už jako extensi nebo jako feature.

Pokud jde o bezpečnost, poměrně pečlivě jsem promýšlel jednotlivé možnosti a dospěl k závěru, že risika existují, ale jsou relativně velmi nízká. Je třeba rozlišovat různé druhy útoků:

1. Má-li útočník přístup k rootu nebo je bezpečnost serveru kompromitována ekvivalentním způsobem, není co řešit: takovému útoku se neubrání žádný systém, který bude mít v kterýkoli okamžik přístup k dešifrovaným hlasům. Pokoušel jsem se vymyslet variantu s využitím javascriptu nebo jiného client-side prostředku tak, aby se na server hlasy vůbec nedostaly, ale nepodařilo se přijít na nic použitelného.
2. Systém je fatálně zranitelný i vůči útočníkovi, který může zapisovat skripty, u systému jako je Wikipedie je takový uživatel fakticky na úrovní roota - velmi pochybuji, že tento přístup mají sami developeři (committers), těm by měl stačit přístup do databáse, aby mohli ladit na živých datech - a i to je otázka. Útočník s takovými privilegii ovšem prolomí každou ochranu, takže ani varianta H proti němu není bezpečná.
3. Dostane-li se útočník k jinému účtu, systém je před ním bezpečný, protože adresáře, ze kterých čte php skripty, nejsou world-writeable (nejvýš 775) a soukromý Apachův klíč je (nejvýš) 660, takže si může nejvýš přečíst skripty a pokud mají bezpečnost děravou, dostane se pomocí hesla přečteného z LocalSettings.php do mysql.
4. Důležité je chránit hlasy před možností pozdějšího útoku např. osobou, která získá přístup k serveru (opakuji, že není moc pravděpodobné, že by taková osoba mohla sama spouštět své skripty ze živého serveru). Protože údaje o tom, jak kdo hlasoval, se ihned po sečtení smažou, je nebezpečí prozrazení relativně malé, menší než risiko, že se někdo dostane k údajům o hlasování a zároveň získá - např. pod záminkou nedůvěry správcům - komunitní klíč csarbcomvote ve variantě H.

--Tompecina 18:05, 2. 12. 2005 (UTC)

Jenom pár poznámek:

• nejsem si jist, co je vlastně míněno rozdílem mezi feature a extenzí. Pokud je tím myšleno to, zda bude implementace roztroušena přímo do zbytku kódu MW ("featura"), nebo bude v oddělených souborech a do zbytku se zapojovat pomocí hooků ("extenze"), pak IMHO featura nemá u vývojářů šanci na přijetí. (To je ovšem jen můj názor založený na nevelkých zkušenostech vývoje MW, vývojář nejsem a ani s nimi nechodím do hospody. ;-) )
• Již delší dobu jede Wikipedie z CVS HEADu, takže pokud má útočník právo commitovat, dokáže tím automaticky svůj skript dostat na server (po takovém útoku však samozřejmě zůstane stopa v CVS). Privilegia všech jednotlivých vývojářů lze nalézt na meta:Developers.
• Nesouhlasím s tím, že by se útokům roota (et al.) neubránil nikdo. Nejdůležitější třídou útoku je IMHO zmanipulování výsledku voleb (oproti jejich utajení, které je pro mě druhotné). Proto je pro mě nutnost důvěřovat úředníkům, že výsledky spočítají správně, dost silný požadavek (podotýkám, že nejde o mou nedůvěru těmto úředníkům, ať už jimi bude kdokoli, ale o to, aby takové volby posléze nebylo možno takto zpochybnit). A proti této třídě útoků je IMHO dostatečnou ochranou možnost ověření, že můj hlas byl započítán správně, např. tak, že každý uživatel při volbě získá náhodný řetězec a u výsledků hlasování je zobrazen celý seznam platných hlasů a u každého příslušný náhodný řetězec. Tak si může každý ověřit, že celkový součet hlasů sedí a můj hlas byl započítán správně, a přitom jsou volby stále tajné.
• Opakuji, že obrana před útočníkem s přístupem k serveru pro mě není příliš podstatná.

--Mormegil ✉ 18:47, 2. 12. 2005 (UTC)

Pokud bude featura dobrá a bude řešit problém společný všem wiki, šanci má, ale ani extense není neřešitelný problém. Díky za link na privilegia, je zjevné, že committeři, kromě cca. 10 nejvyšších, se na server nedostanou, a "útok committem" je profesionální sebevražda. Mýlíte se ale, jestliže tvrdíte (tvrdíte-li to), že u methody H může každý výsledek ověřit, protože uvidí svůj zakódovaný hlas. Nemá-li heslo k rozšifrování, nemá jistotu, že součty sedí. Naopak transparentní algorithmus G dává vysoký stupeň ochrany před manipulací i před prozrazením. --Tompecina 18:59, 2. 12. 2005 (UTC)

Na druhé přečtení mi došlo, jak to myslíte. To je přirozeně nedostatečné, protože ještě byste musel zařídit, že dva uživatelé nedostanou stejný kontrolní kód. Jako útočník bych to právě tak udělal: dal bych pěti stejný kontrolní kód, takže by svůj hlas "viděli", čímž bych získal čtyři hlasy k manipulaci. --Tompecina 19:19, 2. 12. 2005 (UTC)

Myslím, že ani napodruhé nedošlo k úplnému pochopení mé myšlenky. ;-) Při odevzdání hlasu uživatel získá náhodný řetězec. Po ukončení voleb je veřejně zobrazen seznam všech hlasů, u každého z nich je také uveden příslušný řetězec. Tedy např. "46FD4645E54D54C4: Pro Štaflíka, proti Špagetkovi, u Vochomůrky se zdržuje; 5F54545D124E65FA: Proti Štaflíkovi, proti Špagetkovi, pro Vochomůrku; atd." U takového seznamu nevím, kdo jak hlasoval, ale mohu si ověřit celkový součet hlasů, stejně jako to, že můj hlas (který si v tomto seznamu najdu podle kódu) je započítán právně, aniž by utrpěla tajnost voleb; více stejných kódů by mohlo být použito jen pro stejně hlasující, ochranou proti takovému útoku (který by ovšem musel proběhnout už v okamžiku hlasování, nikoli ex post!) by bylo umožnit uživateli zvolit si kód (příp. nabídnout mu vygenerování jiného apod.). --Mormegil ✉ 20:16, 2. 12. 2005 (UTC)

P.S. Co se týče feature/extenze, nemyslím, že má smysl o tom debatovat, na věci stejně nic nezměníme, jenom na to upozorňuji předem. Uvědomte si, že spousta již používaných věcí na Wikipedii je implementována jako extenze. Vizte [2].

Tudy, myslím, cesta nevede, a to ze dvou důvodů: 1. U jednoduchých hlasování bude počet shodných hlasů vysoký. 2. Zobrazením celých hlasovacích lístků (anonymisovaně) porušujete tajnost voleb. Víte-li že, určitě nebudu volit za sysopy Štaflíka, Špagetku ani Káťu (se kterými mám pořád spory), ale zřejmě podpořím Škubánka, který je v komunitě sice prudce neoblíben, ale je to můj kamarád, dovtípíte se s vysokou mírou jistoty, jak jsem hlasoval u Puňti a Alíka. To jde proti principu tajnosti voleb a IMHO to není přijatelné. Volba kontrolního kódu je lepší nápad, ale nutně k tomu potřebujete vedlejší kanál (např. e-mail), na kterém si uživatelé potvrdí, že vidí totéž, a nikdo jim výsledky nemanipuluje. Osobně vidím jako nejsilnější prostředek, jak se bránit proti manipulaci, ve veřejnosti a relativní jednoduchosti algorithmu (moje skripty pro variantu G se vejdou do 1000 řádků php, takže nikdo nebude mít problém zkontrolovat, jestli dělají, co mají, a jejich shoda s veřejně přístupným checkoutem CVS je zaručena integritou vývojářské komunity). --Tompecina 20:30, 2. 12. 2005 (UTC)