Cześć,
mam rokminkę -- mam wrażenie, że to powinno być możliwe, ale nie mogę w tej chwili ogarnąć, czy faktycznie jest, i czy przypadkiem jakiś soft już tego nie potrafi.
O co biega.
Czy możliwy jest do zaimplementowania system, w którym:
1. obywatel idzie do urzędu/instytucji/trusted third party, tam generowany jest para kluczy, certyfikat, podpis cyfrowy, cokolwiek -- jakiś token kryptograficzny;
2. obywatel chce wziąć udział w konsultacjach społecznych; w tym celu musi udowodnić, że ma prawo wziąć w nich udział, więc używa tokenu, ale...
3. …w taki sposób, że urząd może stwierdzić, że faktycznie został użyty wydany przez ten urząd token, ale
4. ...tenże urząd nie ma żadnej możliwości ustalenia, który dokładnie token został użyty (czyli: który obywatel wygłosił dany głos).
Słowem chodzi o system, w którym jesteśmy w stanie zweryfikować, że coś zostało podpisane kluczem jednej z osób z jakiejś grupy, ale jednocześnie nie jesteśmy w stanie sprawdzić, która to dokładnie osoba.
Dnia środa, 28 maja 2014 17:47:09 Michal Andrzejczak pisze:
Słowem chodzi o system, w którym jesteśmy w stanie zweryfikować, że coś zostało podpisane kluczem jednej z osób z jakiejś grupy, ale jednocześnie nie jesteśmy w stanie sprawdzić, która to dokładnie osoba.
To się nazywa bitcoin.
Nie, nie nazywa się. W BitCoinie jest jednoznaczne, trwałe powiązanie między transakcjami a portfelem. Rozwiązanie, o którym mówię, musiałoby: - dać możliwość udowodnienia, że należy się do pewnej grupy - bez możliwości ustalenia, którą z osób należących do tej grupy jesteśmy.
Czyli możliwość robienia potwierdzonych transakcji w oderwaniu od możliwości sprawdzenia, który portfel daną transakcję wykonał.
- udział mogą wziąć tylko osoby z danej grupy (mieszkańcy gminy, na przykład); - dać możliwość udowodnienia, że należy się do pewnej grupy
A więc, wiemy że osobnik A jest mieszkańcem Krakowa, mieszkańcem dzielnicy V, mieszkańcem bloku Z przy ulicy X, w wieku 47-48 lat, mężczyzną, absolwentem XIX liceum, zwolennikiem budowy ścieżek do jazdy konnej w centrum miasta. Moc tego zbioru wydaje się pokaźna. Nie mamy wprawdzie możliwości ustalenia którą z osób należących do tej grupy jesteśmy, ale możemy być jedyną.
Serdecznie pozdrawiam / Best regards,
Jakub Kramarz http://about.me/jkramarz
W dniu 28 maja 2014 18:35 użytkownik rysiek rysiek@hackerspace.pl napisał:
Dnia środa, 28 maja 2014 17:47:09 Michal Andrzejczak pisze:
Słowem chodzi o system, w którym jesteśmy w stanie zweryfikować, że coś zostało podpisane kluczem jednej z osób z jakiejś grupy, ale
jednocześnie
nie jesteśmy w stanie sprawdzić, która to dokładnie osoba.
To się nazywa bitcoin.
Nie, nie nazywa się. W BitCoinie jest jednoznaczne, trwałe powiązanie między transakcjami a portfelem. Rozwiązanie, o którym mówię, musiałoby:
- dać możliwość udowodnienia, że należy się do pewnej grupy
- bez możliwości ustalenia, którą z osób należących do tej grupy jesteśmy.
Czyli możliwość robienia potwierdzonych transakcji w oderwaniu od możliwości sprawdzenia, który portfel daną transakcję wykonał.
-- Pozdr rysiek _______________________________________________ General mailing list General@lists.hackerspace.pl https://lists.hackerspace.pl/mailman/listinfo/general
Dnia środa, 28 maja 2014 18:51:17 Jakub Kramarz pisze:
- udział mogą wziąć tylko osoby z danej grupy (mieszkańcy gminy, na przykład);
- dać możliwość udowodnienia, że należy się do pewnej grupy
A więc, wiemy że osobnik A jest mieszkańcem Krakowa, mieszkańcem dzielnicy V, mieszkańcem bloku Z przy ulicy X, w wieku 47-48 lat, mężczyzną, absolwentem XIX liceum, zwolennikiem budowy ścieżek do jazdy konnej w centrum miasta. Moc tego zbioru wydaje się pokaźna. Nie mamy wprawdzie możliwości ustalenia którą z osób należących do tej grupy jesteśmy, ale możemy być jedyną.
No to pytanie, na którym poziomie postawimy "odcięcie" informacji. Moim zdaniem sensowne jest odcięcie na poziomie gminy lub okręgu wyborczego.
Czyli: token (ten wygenerowany, użyty do wzięcia udziału w konkretnym procesie konsultacyjnym konsultacji, na podstawie klucza uzyskanego w urzędzie czy komisji wyborczej) pozwala ustalić, że został wygenerowany właśnie na podstawie *któregoś* klucza wydanego przez *ten konkretny* urząd/tę konkretną komisję. I *tylko* tyle.
To jest odpowiednik pokazywania dowodu przy głosowaniu, ale głosowania za kotarą i wrzucając do urny. Tylko rozszerzony o: - udział "elektroniczny"; - możliwość nie tylko głosowania, ale dyskusji.
W dniu 28.05.2014 19:15, rysiek pisze:
Dnia środa, 28 maja 2014 18:51:17 Jakub Kramarz pisze:
- udział mogą wziąć tylko osoby z danej grupy (mieszkańcy gminy, na przykład);
- dać możliwość udowodnienia, że należy się do pewnej grupy
A więc, wiemy że osobnik A jest mieszkańcem Krakowa, mieszkańcem dzielnicy V, mieszkańcem bloku Z przy ulicy X, w wieku 47-48 lat, mężczyzną, absolwentem XIX liceum, zwolennikiem budowy ścieżek do jazdy konnej w centrum miasta. Moc tego zbioru wydaje się pokaźna. Nie mamy wprawdzie możliwości ustalenia którą z osób należących do tej grupy jesteśmy, ale możemy być jedyną.
No to pytanie, na którym poziomie postawimy "odcięcie" informacji. Moim zdaniem sensowne jest odcięcie na poziomie gminy lub okręgu wyborczego.
Czyli: token (ten wygenerowany, użyty do wzięcia udziału w konkretnym procesie konsultacyjnym konsultacji, na podstawie klucza uzyskanego w urzędzie czy komisji wyborczej) pozwala ustalić, że został wygenerowany właśnie na podstawie *któregoś* klucza wydanego przez *ten konkretny* urząd/tę konkretną komisję. I *tylko* tyle.
To jest odpowiednik pokazywania dowodu przy głosowaniu, ale głosowania za kotarą i wrzucając do urny. Tylko rozszerzony o:
- udział "elektroniczny";
- możliwość nie tylko głosowania, ale dyskusji.
No to może najprościej - klucz OpenPGP z normalnym unikalnym id, ale nazwą jedynie "Mieszkaniec gminy X", klucz musi być podpisany przez klucz urzędu miasta z tej gminy. Urząd za to u siebie przechowuje tylko informację czy danemu mieszkańcowi podpisano klucz, ale nie wie który id klucza (ta informacja byłaby znana innym urzędom, żeby jedna osoba nie mogła uzyskać wielu podpisanych kluczy).
Dnia środa, 28 maja 2014 21:27:18 Łukasz "Cyber Killer" Korpalski pisze:
W dniu 28.05.2014 19:15, rysiek pisze:
Dnia środa, 28 maja 2014 18:51:17 Jakub Kramarz pisze:
udział mogą wziąć tylko osoby z danej grupy (mieszkańcy gminy, na
przykład);
dać możliwość udowodnienia, że należy się do pewnej grupy
A więc, wiemy że osobnik A jest mieszkańcem Krakowa, mieszkańcem dzielnicy V, mieszkańcem bloku Z przy ulicy X, w wieku 47-48 lat, mężczyzną, absolwentem XIX liceum, zwolennikiem budowy ścieżek do jazdy konnej w centrum miasta. Moc tego zbioru wydaje się pokaźna. Nie mamy wprawdzie możliwości ustalenia którą z osób należących do tej grupy jesteśmy, ale możemy być jedyną.
No to pytanie, na którym poziomie postawimy "odcięcie" informacji. Moim zdaniem sensowne jest odcięcie na poziomie gminy lub okręgu wyborczego.
Czyli: token (ten wygenerowany, użyty do wzięcia udziału w konkretnym procesie konsultacyjnym konsultacji, na podstawie klucza uzyskanego w urzędzie czy komisji wyborczej) pozwala ustalić, że został wygenerowany właśnie na podstawie *któregoś* klucza wydanego przez *ten konkretny* urząd/tę konkretną komisję. I *tylko* tyle.
To jest odpowiednik pokazywania dowodu przy głosowaniu, ale głosowania za
kotarą i wrzucając do urny. Tylko rozszerzony o:
- udział "elektroniczny";
- możliwość nie tylko głosowania, ale dyskusji.
No to może najprościej - klucz OpenPGP z normalnym unikalnym id, ale nazwą jedynie "Mieszkaniec gminy X", klucz musi być podpisany przez klucz urzędu miasta z tej gminy. Urząd za to u siebie przechowuje tylko informację czy danemu mieszkańcowi podpisano klucz, ale nie wie który id klucza (ta informacja byłaby znana innym urzędom, żeby jedna osoba nie mogła uzyskać wielu podpisanych kluczy).
Dobry kierunek (i zwrot), ale chyba to jeszcze nie to. Chodzi o takie rozwiązanie, w którym urząd nie ma żadnej możliwości zdobycia informacji o tożsamości danego wypowiadającego się.
W Twoim pomyśle musimy *zaufać* urzędowi, że nie zanotuje sobie przy wydawaniu klucza, komu dany klucz wydał...
On 29.05.2014 10:02, rysiek wrote:
W Twoim pomyśle musimy *zaufać* urzędowi, że nie zanotuje sobie przy wydawaniu klucza, komu dany klucz wydał...
Zastanawiam sie jak nisko należałoby zejść aby spełnić jak najbardziej paranoiczne z zastrzeżeń, czy da się inaczej niż pozbawiając frontend softu, którym urzędnik wydawałby klucz widoku owego klucza zagwarantować, że niecny urzędnik nie zechce zobaczyć jaki masz odcisk/klucz... A co z tym, że w pamięci komputera dalej będą gdzieś dane właśnie wygenerowanego klucza, i jak odejdziesz od okienka, to będzie można je wydobyć ? Czyżby należało wyeliminować zarówno czynnik ludzki i komputery ?
Dnia czwartek, 29 maja 2014 12:39:48 Wiktor Przybylski pisze:
On 29.05.2014 10:02, rysiek wrote:
W Twoim pomyśle musimy *zaufać* urzędowi, że nie zanotuje sobie przy wydawaniu klucza, komu dany klucz wydał...
Zastanawiam sie jak nisko należałoby zejść aby spełnić jak najbardziej paranoiczne z zastrzeżeń, czy da się inaczej niż pozbawiając frontend softu, którym urzędnik wydawałby klucz widoku owego klucza zagwarantować, że niecny urzędnik nie zechce zobaczyć jaki masz odcisk/klucz... A co z tym, że w pamięci komputera dalej będą gdzieś dane właśnie wygenerowanego klucza, i jak odejdziesz od okienka, to będzie można je wydobyć ? Czyżby należało wyeliminować zarówno czynnik ludzki i komputery ?
Ale dlatego pytam o rozwiązanie kryptograficzne, które *zagwarantuje*, że nawet, gdy urząd zna klucze, który wydał obywatelom, i które klucze wydał którym obywatelom, nie dawało to możliwości ustalenia, który obywatel wygłosił który głos.
On 2014-05-28 18:35, rysiek wrote:
Dnia środa, 28 maja 2014 17:47:09 Michal Andrzejczak pisze:
Słowem chodzi o system, w którym jesteśmy w stanie zweryfikować, że coś zostało podpisane kluczem jednej z osób z jakiejś grupy, ale jednocześnie nie jesteśmy w stanie sprawdzić, która to dokładnie osoba.
To się nazywa bitcoin.
Nie, nie nazywa się. W BitCoinie jest jednoznaczne, trwałe powiązanie między transakcjami a portfelem. Rozwiązanie, o którym mówię, musiałoby:
- dać możliwość udowodnienia, że należy się do pewnej grupy
- bez możliwości ustalenia, którą z osób należących do tej grupy
jesteśmy.
Czyli możliwość robienia potwierdzonych transakcji w oderwaniu od możliwości sprawdzenia, który portfel daną transakcję wykonał.
Taki trochę anonimowy bitcoin? :v
Dnia środa, 28 maja 2014 22:48:08 spin@hackerspace.pl pisze:
On 2014-05-28 18:35, rysiek wrote:
Dnia środa, 28 maja 2014 17:47:09 Michal Andrzejczak pisze:
Słowem chodzi o system, w którym jesteśmy w stanie zweryfikować, że coś zostało podpisane kluczem jednej z osób z jakiejś grupy, ale jednocześnie nie jesteśmy w stanie sprawdzić, która to dokładnie osoba.
To się nazywa bitcoin.
Nie, nie nazywa się. W BitCoinie jest jednoznaczne, trwałe powiązanie między
transakcjami a portfelem. Rozwiązanie, o którym mówię, musiałoby:
- dać możliwość udowodnienia, że należy się do pewnej grupy
- bez możliwości ustalenia, którą z osób należących do tej grupy
jesteśmy.
Czyli możliwość robienia potwierdzonych transakcji w oderwaniu od możliwości sprawdzenia, który portfel daną transakcję wykonał.
Taki trochę anonimowy bitcoin? :v
Trochę: http://en.wikipedia.org/wiki/Zerocoin
Ale nie do końca:
W dniu 28.05.2014 17:41, rysiek pisze:
Słowem chodzi o system, w którym jesteśmy w stanie zweryfikować, że coś zostało podpisane kluczem jednej z osób z jakiejś grupy, ale jednocześnie nie jesteśmy w stanie sprawdzić, która to dokładnie osoba.
Witaj,
Tak, jest to możliwe i ostatnio słyszałem o pracy naukowej na ten temat. Jednocześnie nie jestem wstanie jej znaleźć w tej chwili. Jak tylko znajdę podlinkuję.
W dniu 28.05.2014 17:55, Łukasz Dubiel pisze:
W dniu 28.05.2014 17:41, rysiek pisze:
Słowem chodzi o system, w którym jesteśmy w stanie zweryfikować, że coś zostało podpisane kluczem jednej z osób z jakiejś grupy, ale jednocześnie nie jesteśmy w stanie sprawdzić, która to dokładnie osoba.
Witaj,
Tak, jest to możliwe i ostatnio słyszałem o pracy naukowej na ten temat. Jednocześnie nie jestem wstanie jej znaleźć w tej chwili. Jak tylko znajdę podlinkuję.
Wspomniany dokument http://oleganza.com/blind-ecdsa-draft-v2.pdf
2014-05-28 22:21 GMT+02:00 Łukasz Dubiel lukasz@hackerspace-krk.pl:
W dniu 28.05.2014 17:55, Łukasz Dubiel pisze:
W dniu 28.05.2014 17:41, rysiek pisze:
Słowem chodzi o system, w którym jesteśmy w stanie zweryfikować, że coś zostało podpisane kluczem jednej z osób z jakiejś grupy, ale jednocześnie nie jesteśmy w stanie sprawdzić, która to dokładnie osoba.
Witaj,
Tak, jest to możliwe i ostatnio słyszałem o pracy naukowej na ten temat. Jednocześnie nie jestem wstanie jej znaleźć w tej chwili. Jak tylko znajdę podlinkuję.
Wspomniany dokument http://oleganza.com/blind-ecdsa-draft-v2.pdf
To tak nie działa, opublikowane informacje są "nieślepe". To nie jest protokół do broadcastu.
(Plus jest bardzo silne wymaganie, aby parametry krzywej eliptycznej w pierwszym kroku były niepowtarzalne... Dużo wiadomości i masz gwarancję, że zbiór mocnych n-bitowych krzywych szybko się skurczy.)
A poza tym: "The security of the scheme depends on Bob providing secure authentication separately from Alice’s secrets, so only Alice herself (not someone who stole all her secrets) can demand a valid signature from Bob."
Czyt. nie rozwiązuje problemu niezaufanego urzędu podpisującego.
R.
Rysiek,
Rzuć sobie okiem na ten papierek http://arxiv.org/pdf/0908.0979.pdf, powinien Cię zaciekawić.
Zegar out.
2014-05-28 17:41 GMT+02:00 rysiek rysiek@hackerspace.pl:
Cześć,
mam rokminkę -- mam wrażenie, że to powinno być możliwe, ale nie mogę w tej chwili ogarnąć, czy faktycznie jest, i czy przypadkiem jakiś soft już tego nie potrafi.
O co biega.
Czy możliwy jest do zaimplementowania system, w którym:
- obywatel idzie do urzędu/instytucji/trusted third party, tam generowany
jest para kluczy, certyfikat, podpis cyfrowy, cokolwiek -- jakiś token kryptograficzny;
- obywatel chce wziąć udział w konsultacjach społecznych; w tym celu musi
udowodnić, że ma prawo wziąć w nich udział, więc używa tokenu, ale...
- …w taki sposób, że urząd może stwierdzić, że faktycznie został użyty
wydany przez ten urząd token, ale
- ...tenże urząd nie ma żadnej możliwości ustalenia, który dokładnie token
został użyty (czyli: który obywatel wygłosił dany głos).
Słowem chodzi o system, w którym jesteśmy w stanie zweryfikować, że coś zostało podpisane kluczem jednej z osób z jakiejś grupy, ale jednocześnie nie jesteśmy w stanie sprawdzić, która to dokładnie osoba.
-- Pozdr rysiek _______________________________________________ General mailing list General@lists.hackerspace.pl https://lists.hackerspace.pl/mailman/listinfo/general
https://eprint.iacr.org/2013/622.pdf to również może Cię zainteresować, ciekawa propozycja rozwiązania.
Zegar out.
2014-05-28 18:00 GMT+02:00 Paweł Zegartowski pzegar@gmail.com:
Rysiek,
Rzuć sobie okiem na ten papierek http://arxiv.org/pdf/0908.0979.pdf, powinien Cię zaciekawić.
Zegar out.
2014-05-28 17:41 GMT+02:00 rysiek rysiek@hackerspace.pl:
Cześć,
mam rokminkę -- mam wrażenie, że to powinno być możliwe, ale nie mogę w tej chwili ogarnąć, czy faktycznie jest, i czy przypadkiem jakiś soft już tego nie potrafi.
O co biega.
Czy możliwy jest do zaimplementowania system, w którym:
- obywatel idzie do urzędu/instytucji/trusted third party, tam generowany
jest para kluczy, certyfikat, podpis cyfrowy, cokolwiek -- jakiś token kryptograficzny;
- obywatel chce wziąć udział w konsultacjach społecznych; w tym celu musi
udowodnić, że ma prawo wziąć w nich udział, więc używa tokenu, ale...
- …w taki sposób, że urząd może stwierdzić, że faktycznie został użyty
wydany przez ten urząd token, ale
- ...tenże urząd nie ma żadnej możliwości ustalenia, który dokładnie
token został użyty (czyli: który obywatel wygłosił dany głos).
Słowem chodzi o system, w którym jesteśmy w stanie zweryfikować, że coś zostało podpisane kluczem jednej z osób z jakiejś grupy, ale jednocześnie nie jesteśmy w stanie sprawdzić, która to dokładnie osoba.
-- Pozdr rysiek _______________________________________________ General mailing list General@lists.hackerspace.pl https://lists.hackerspace.pl/mailman/listinfo/general
-- Pozdrawiam, Paweł Zegartowski
Dnia środa, 28 maja 2014 18:03:50 Paweł Zegartowski pisze:
https://eprint.iacr.org/2013/622.pdf to również może Cię zainteresować, ciekawa propozycja rozwiązania.
Dzięks, reading.
Tako rzecze rysiek (2014-05-28, 17:41):
mam rokminkę -- mam wrażenie, że to powinno być możliwe, ale nie mogę w tej chwili ogarnąć, czy faktycznie jest, i czy przypadkiem jakiś soft już tego nie potrafi.
http://crypto.stackexchange.com/questions/3474/approach-towards-anonymous-e-... http://crypto.stanford.edu/pbc/notes/crypto/voting.xhtml
Nie znam konkretnych implementacji w softwarze, ale temat jest chyba zasadniczo rozkminiony.
Dnia środa, 28 maja 2014 18:03:42 antoszka pisze:
Tako rzecze rysiek (2014-05-28, 17:41):
mam rokminkę -- mam wrażenie, że to powinno być możliwe, ale nie mogę w tej chwili ogarnąć, czy faktycznie jest, i czy przypadkiem jakiś soft już tego nie potrafi.
http://crypto.stackexchange.com/questions/3474/approach-towards-anonymous-e-... voting http://crypto.stanford.edu/pbc/notes/crypto/voting.xhtml
Nie znam konkretnych implementacji w softwarze, ale temat jest chyba zasadniczo rozkminiony.
Ale nie chodzi tylko o głosowanie. Chodzi o zabieranie głosu w sensie wypowiedzi w dyskusji. Dyskusji, w której: - udział mogą wziąć tylko osoby z danej grupy (mieszkańcy gminy, na przykład); - możliwość śledzenia wypowiedzi konkretnej osoby (identyfikowanej numerem, sumą kontrolną, pseudonimem, etc) - ale nie chcemy technicznej możliwości ustalenia, który pseudonim do kogo należy.
hej,
W dniu 28 maja 2014 18:42 użytkownik rysiek rysiek@hackerspace.pl napisał:
Dnia środa, 28 maja 2014 18:03:42 antoszka pisze:
Tako rzecze rysiek (2014-05-28, 17:41):
mam rokminkę -- mam wrażenie, że to powinno być możliwe, ale nie mogę w tej chwili ogarnąć, czy faktycznie jest, i czy przypadkiem jakiś soft już tego nie potrafi.
http://crypto.stackexchange.com/questions/3474/approach-towards-anonymous-e-... voting http://crypto.stanford.edu/pbc/notes/crypto/voting.xhtml
Nie znam konkretnych implementacji w softwarze, ale temat jest chyba zasadniczo rozkminiony.
Ale nie chodzi tylko o głosowanie. Chodzi o zabieranie głosu w sensie wypowiedzi w dyskusji. Dyskusji, w której:
- udział mogą wziąć tylko osoby z danej grupy (mieszkańcy gminy, na przykład);
- możliwość śledzenia wypowiedzi konkretnej osoby (identyfikowanej numerem, sumą kontrolną, pseudonimem, etc)
- ale nie chcemy technicznej możliwości ustalenia, który pseudonim do kogo należy.
Ale co to za różnica? W e-głosowaniu też chodzi o to, by mieć gwarancję, że dany głos został oddany przez osobę uprawnioną, z danego okręgu. A to czy "głos" polega na zaznaczeniu kratki przy nazwisku kandydata, czy przesłaniu kawałka swojej wypowiedzi w TXT / PDF, to przecież bez znaczenia.
Chyba, że czegoś ważnego nie rozumiem w tym co mówisz, co nie jest wykluczone ;)
Dnia środa, 28 maja 2014 19:09:49 Jaroslaw Gorny pisze:
hej,
W dniu 28 maja 2014 18:42 użytkownik rysiek rysiek@hackerspace.pl napisał:
Dnia środa, 28 maja 2014 18:03:42 antoszka pisze:
Tako rzecze rysiek (2014-05-28, 17:41):
mam rokminkę -- mam wrażenie, że to powinno być możliwe, ale nie mogę w tej chwili ogarnąć, czy faktycznie jest, i czy przypadkiem jakiś soft już tego nie potrafi.
http://crypto.stackexchange.com/questions/3474/approach-towards-anonymous -e-> voting http://crypto.stanford.edu/pbc/notes/crypto/voting.xhtml
Nie znam konkretnych implementacji w softwarze, ale temat jest chyba zasadniczo rozkminiony.
Ale nie chodzi tylko o głosowanie. Chodzi o zabieranie głosu w sensie
wypowiedzi w dyskusji. Dyskusji, w której:
udział mogą wziąć tylko osoby z danej grupy (mieszkańcy gminy, na
przykład);
możliwość śledzenia wypowiedzi konkretnej osoby (identyfikowanej
numerem,
sumą kontrolną, pseudonimem, etc)
- ale nie chcemy technicznej możliwości ustalenia, który pseudonim do
kogo
należy.
Ale co to za różnica? W e-głosowaniu też chodzi o to, by mieć gwarancję, że dany głos został oddany przez osobę uprawnioną, z danego okręgu. A to czy "głos" polega na zaznaczeniu kratki przy nazwisku kandydata, czy przesłaniu kawałka swojej wypowiedzi w TXT / PDF, to przecież bez znaczenia.
Chyba, że czegoś ważnego nie rozumiem w tym co mówisz, co nie jest wykluczone ;)
Nie chodzi tylko o głosowanie. Chodzi również (albo: przede wszystkim!) o wypowiadanie się w konsultacjach społecznych, pełnymi zdaniami. I robienie tego właśnie elektronicznie, w sposób gwarantujący: - możliwość sprawdzenia, że dany uczestnik jest uprawniony; - brak możliwości ustalenia, który to dokładnie z grupy uprawnionych.
Nie chodzi tylko o głosowanie. Chodzi również (albo: przede wszystkim!) o wypowiadanie się w konsultacjach społecznych, pełnymi zdaniami. I robienie tego właśnie elektronicznie, w sposób gwarantujący:
- możliwość sprawdzenia, że dany uczestnik jest uprawniony;
- brak możliwości ustalenia, który to dokładnie z grupy uprawnionych.
Do weryfikacji uprawnień, można by zastosować hierarchię kluczy, Kraj->Województwo->Gmina->Powiat->Miasto->ew. dzielnica W sytuacji konsultacji na różnym poziomie jest sprawdzane prawo do głosowania na bazie ścieżki. Urząd wydawałby certyfikat na bazie jakiejś tam sumy kontrolnej, a w swojej bazie miał prawo do zmiany pola WYDANO(TAK/NIE) bez zaznaczania kto jest kim.
Pytanie czy to musi być w pełny wirtualny klucz lub certyfikat. Ostatnio testowałem rozwiązanie z hardware'owym tokenem gdzie zaimplementowanie czegoś takiego było by banalne.
On Wed, May 28, 2014 at 07:17:20PM +0200, rysiek wrote:
Nie chodzi tylko o głosowanie. Chodzi również (albo: przede wszystkim!) o wypowiadanie się w konsultacjach społecznych, pełnymi zdaniami. I robienie tego właśnie elektronicznie, w sposób gwarantujący:
- możliwość sprawdzenia, że dany uczestnik jest uprawniony;
- brak możliwości ustalenia, który to dokładnie z grupy uprawnionych.
A to algorytmy do głosowania elektronicznego nie są ogarnięte? W takim przypadku wystarczyłoby, by obywatel zamiast podpisywać głos, podpisywał klucz stworzony przez siebie, a następnie posługiwał się tym kluczem w dyskusji?
2014-05-28 23:19 GMT+02:00 Piotr Pies Ostrowski hackerspace@314es.pl:
A to algorytmy do głosowania elektronicznego nie są ogarnięte? W takim przypadku wystarczyłoby, by obywatel zamiast podpisywać głos, podpisywał klucz stworzony przez siebie, a następnie posługiwał się tym kluczem w dyskusji?
Głosowanie to komunikacja 1:1, do tego jednorazowa i jednokierunkowa. (źródło głosu -> urna)
Rysio postuluje system N:N do dyskusji.
On Wed, May 28, 2014 at 11:34:34PM +0200, Radoslaw Szkodzinski wrote:
2014-05-28 23:19 GMT+02:00 Piotr Pies Ostrowski hackerspace@314es.pl:
A to algorytmy do głosowania elektronicznego nie są ogarnięte? W takim przypadku wystarczyłoby, by obywatel zamiast podpisywać głos, podpisywał klucz stworzony przez siebie, a następnie posługiwał się tym kluczem w dyskusji?
Głosowanie to komunikacja 1:1, do tego jednorazowa i jednokierunkowa. (źródło głosu -> urna)
Rysio postuluje system N:N do dyskusji.
No dokładnie, kwestia tylko by zamiast komunikatu "Głosuję na X" przekazać "Dodaję do puli klucz o wartości xyz". W ten sposób istnieje klucz który wiadomo, że należy do osoby uprawnionej ale nie wiadomo do kogo konkretnie (o ile działa algorytm od samego głosowania) a którym obywatel może się posługiwać w dyskusji.
Jak się załatwi kwestię kluczy to już chyba dalej nie ma problemu, równie dobrze możesz przez tora wysyłać wypowiedzi podpisane swoim obywatelskim kluczem i zaszyfrowane publicznym kluczem komisji?
2014-05-28 23:53 GMT+02:00 Piotr Pies Ostrowski hackerspace@314es.pl:
On Wed, May 28, 2014 at 11:34:34PM +0200, Radoslaw Szkodzinski wrote:
2014-05-28 23:19 GMT+02:00 Piotr Pies Ostrowski hackerspace@314es.pl:
A to algorytmy do głosowania elektronicznego nie są ogarnięte? W takim przypadku wystarczyłoby, by obywatel zamiast podpisywać głos, podpisywał klucz stworzony przez siebie, a następnie posługiwał się tym kluczem w dyskusji?
Głosowanie to komunikacja 1:1, do tego jednorazowa i jednokierunkowa. (źródło głosu -> urna)
Rysio postuluje system N:N do dyskusji.
No dokładnie, kwestia tylko by zamiast komunikatu "Głosuję na X" przekazać "Dodaję do puli klucz o wartości xyz".
Trochę trudniej, ponieważ podrobienie numerka kandydata jest ok, a podrobienie klucza nie. Ale dodatkowo pojawia się problem dystrybucji tego komunikatu w taki sposób, aby nie ujawnić lokalizacji.
R.
On Thu, May 29, 2014 at 12:00:28AM +0200, Radoslaw Szkodzinski wrote:
2014-05-28 23:53 GMT+02:00 Piotr Pies Ostrowski hackerspace@314es.pl:
On Wed, May 28, 2014 at 11:34:34PM +0200, Radoslaw Szkodzinski wrote:
2014-05-28 23:19 GMT+02:00 Piotr Pies Ostrowski hackerspace@314es.pl:
A to algorytmy do głosowania elektronicznego nie są ogarnięte? W takim przypadku wystarczyłoby, by obywatel zamiast podpisywać głos, podpisywał klucz stworzony przez siebie, a następnie posługiwał się tym kluczem w dyskusji?
Głosowanie to komunikacja 1:1, do tego jednorazowa i jednokierunkowa. (źródło głosu -> urna)
Rysio postuluje system N:N do dyskusji.
No dokładnie, kwestia tylko by zamiast komunikatu "Głosuję na X" przekazać "Dodaję do puli klucz o wartości xyz".
Trochę trudniej, ponieważ podrobienie numerka kandydata jest ok, a podrobienie klucza nie. Ale dodatkowo pojawia się problem dystrybucji tego komunikatu w taki sposób, aby nie ujawnić lokalizacji.
Em... Co rozumiesz przez podrobienie klucza? Co do dystrybucji - dokładnie ten sam problem co przy głosowaniu elektronicznym, mylę się?
Dnia czwartek, 29 maja 2014 00:00:28 Radoslaw Szkodzinski pisze:
2014-05-28 23:53 GMT+02:00 Piotr Pies Ostrowski hackerspace@314es.pl:
On Wed, May 28, 2014 at 11:34:34PM +0200, Radoslaw Szkodzinski wrote:
2014-05-28 23:19 GMT+02:00 Piotr Pies Ostrowski hackerspace@314es.pl:
A to algorytmy do głosowania elektronicznego nie są ogarnięte? W takim przypadku wystarczyłoby, by obywatel zamiast podpisywać głos, podpisywał klucz stworzony przez siebie, a następnie posługiwał się tym kluczem w dyskusji?>>
Głosowanie to komunikacja 1:1, do tego jednorazowa i jednokierunkowa. (źródło głosu -> urna)
Rysio postuluje system N:N do dyskusji.
No dokładnie, kwestia tylko by zamiast komunikatu "Głosuję na X" przekazać "Dodaję do puli klucz o wartości xyz".
Trochę trudniej, ponieważ podrobienie numerka kandydata jest ok, a podrobienie klucza nie. Ale dodatkowo pojawia się problem dystrybucji tego komunikatu w taki sposób, aby nie ujawnić lokalizacji.
Ten drugi problem jest osobną kwestią -- i jak Piotr stwierdził, choćby TOR nam styknie na tym etapie.
W dniu 28 maja 2014 23:53 użytkownik Piotr Pies Ostrowski hackerspace@314es.pl napisał:
2014-05-28 23:19 GMT+02:00 Piotr Pies Ostrowski hackerspace@314es.pl:
A to algorytmy do głosowania elektronicznego nie są ogarnięte?
A jeśli są to zakładają, że komisja wyborcza nie wie komu wydała "kartę do głosowania"? No coś takiego... ;-D
No dokładnie, kwestia tylko by zamiast komunikatu "Głosuję na X" przekazać "Dodaję do puli klucz o wartości xyz". W ten sposób istnieje klucz który wiadomo, że należy do osoby uprawnionej ale nie wiadomo do kogo konkretnie (o ile działa algorytm od samego głosowania) a którym obywatel może się posługiwać w dyskusji.
Wiadomo, że należy do osoby uprawnionej? Zadaj sobie pytanie SKĄD TO WIADOMO.
Jak się załatwi kwestię kluczy to już chyba dalej nie ma problemu
Tu nie chodzi o bezpieczeństwo SZYFROWANIA lub ANONIMOWE SZYFROWANIE tylko o ANONIMOWĄ PUBLIKACJĘ z AUTORYZOWANEGO KRĘGU. Czy paniali wszyscy czy może pójdą po książki??? Zaczynam się kurcze irytować....
Tu nie chodzi o bezpieczeństwo SZYFROWANIA lub ANONIMOWE SZYFROWANIE tylko o ANONIMOWĄ PUBLIKACJĘ z AUTORYZOWANEGO KRĘGU. Czy paniali wszyscy czy może pójdą po książki??? Zaczynam się kurcze irytować....
Idź się odstresuj. Literatura o darknetach jest dostępna i bez martwych drzew. (Freenet.)
Problem polega na uwierzytelnieniu *pseudonimu*. w taki sposób, aby ktoś się pod niego nie mógł łatwo podszyć. Żebyś wiedział, że dyskutujesz z konkretną osobą, a nie trollem podszywającym się pod tę osobę.
R.
W dniu 2014-05-29 00:04, Marek Zibrow pisze:
Tu nie chodzi o bezpieczeństwo SZYFROWANIA lub ANONIMOWE SZYFROWANIE tylko o ANONIMOWĄ PUBLIKACJĘ z AUTORYZOWANEGO KRĘGU. Czy paniali wszyscy czy może pójdą po książki??? Zaczynam się kurcze irytować....
Dopiero teraz zaczynasz się irytować? Jak zobaczyłem "doplątywanie", "teleportację" i "2*n^2 tokenów" w kontekście zastosowania splątania kwantowego, o którym wspomniałeś, to nie wiedziałem, czy się zacząć śmiać czy płakać.
-- BoBsoN
2014-05-29 0:10 GMT+02:00 Robert Partyka bobson@bobson.pl:
Dopiero teraz zaczynasz się irytować? Jak zobaczyłem "doplątywanie", "teleportację" i "2*n^2 tokenów" w kontekście zastosowania splątania kwantowego, o którym wspomniałeś, to nie wiedziałem, czy się zacząć śmiać czy płakać.
Tak, nazywanie splątanego qubitu tokenem jest absolutnie nie na miejscu w kwestiach kryptograficznych... oh wait. (Jest to para idealnie zsynchronizowanych stanów, jedyna różnica jest taka, że zmiany się "przenoszą" między nimi. Są idealnie zsynchronizowane zawsze - w innym przypadku nie są tokenem.)
You need to try harder as well.
W dniu 2014-05-29 00:16, Radoslaw Szkodzinski pisze:
2014-05-29 0:10 GMT+02:00 Robert Partykabobson@bobson.pl:
Dopiero teraz zaczynasz się irytować? Jak zobaczyłem "doplątywanie", "teleportację" i "2*n^2 tokenów" w kontekście zastosowania splątania kwantowego, o którym wspomniałeś, to nie wiedziałem, czy się zacząć śmiać czy płakać.
Tak, nazywanie splątanego qubitu tokenem jest absolutnie nie na miejscu w kwestiach kryptograficznych... oh wait. (Jest to para idealnie zsynchronizowanych stanów, jedyna różnica jest taka, że zmiany się "przenoszą" między nimi. Są idealnie zsynchronizowane zawsze - w innym przypadku nie są tokenem.)
No właśnie udowodniłeś, że nie rozumiesz... no ale to już nie mój problem. Markowi też pewnie nie będzie się chciało tłumaczyć. Lepiej się zająć czymś bardziej kreatywnym.
-- BoBosN
W dniu 29 maja 2014 00:16 użytkownik Radoslaw Szkodzinski astralstorm@gmail.com napisał:
2014-05-29 0:10 GMT+02:00 Robert Partyka bobson@bobson.pl:
Dopiero teraz zaczynasz się irytować? Jak zobaczyłem "doplątywanie", "teleportację" i "2*n^2 tokenów" w kontekście zastosowania splątania kwantowego, o którym wspomniałeś, to nie wiedziałem, czy się zacząć śmiać czy płakać.
Tak, nazywanie splątanego qubitu tokenem jest absolutnie nie na miejscu w kwestiach kryptograficznych... oh wait. (Jest to para idealnie zsynchronizowanych stanów, jedyna różnica jest taka, że zmiany się "przenoszą" między nimi. Są idealnie zsynchronizowane zawsze - w innym przypadku nie są tokenem.)
Słuchaj jednak coś dodam (mimo stresu i późnej pory): powiedz mi czy Ty przeczytałeś o czym jest temat? Czy chodzi naprawdę o kryptografię czy o anonimową autoryzację? Bo może to do Ciebie nie dotarło jeszcze? Jeśli nie to proszę wróć do postu rysia i przeczytaj go jeszcze raz i jeszcze raz i jeszcze 10 raz. Kiedy przyznasz mi już rację to nie musisz dalej czytać. Jeśli nie przyznasz mi racji po dziesiątym razie to wiesz co... przepraszam Cię bo rozmawiamy o zupełnie innych problemach. Zostań z qubitem...
M. zwany Jazonem (zakopany w martwych drzewach)
Przeczytałem dosyć. Potrzeba anonimowej weryfikacji członkowstwa w gminie i pseudonimowej dyskusji. ("możliwość śledzenia wypowiedzi konkretnej osoby")
Rozwiązaniem jest ten algorytm: http://cs.brown.edu/~anna/papers/cl01a.pdf ew. z pewnymi ograniczeniami modyfikacja blind ECDSA (Lidong Chen, w takim periodyku)
W dniu 29 maja 2014 01:02 użytkownik Radoslaw Szkodzinski astralstorm@gmail.com napisał:
Przeczytałem dosyć. Potrzeba anonimowej weryfikacji członkowstwa w gminie i pseudonimowej dyskusji. ("możliwość śledzenia wypowiedzi konkretnej osoby")
Rozwiązaniem jest ten algorytm: http://cs.brown.edu/~anna/papers/cl01a.pdf ew. z pewnymi ograniczeniami modyfikacja blind ECDSA (Lidong Chen, w takim periodyku)
Super. Pierwszy sensowny link w dyskusji (w każdym razie na pewno tytuł publikacji jest na temat). Przeczytam i wrócę w sobotę. Tymczasem pozostaję z silnym przeświadczeniem, że... rzeczony artykuł pokazując teoretyczne możliwości realizacji zawiera wszystkie uwzględnione przeze mnie postulaty powodujące praktyczną nierealizowalność w obecnej praktyce tytułowego zamierzenia.
Zawiera dokładnie jedno trudne założenie: istnienie anonimowego kanału komunikacji do organizacji.
W tym przypadku możemy posłużyć się nieco staromodnym podejściem z MixMiniona... i bardzo długotrwałymi sesjami.
R.
Wiesz niestety... zawiera przynajmniej jeszcze jedno (może inne po prostu przemilcza). Skoro jest napisane: "For all-or-nothing non-transferability, this will make sure that access to one pseudonym or credential of a user is sufficient to obtain access to all of them." ...to zastanawiam się jak wiarygodna będzie realizacja bez spełnienia chociażby postulatu ciągłej dostępności. I cała para idzie w gwizdek a ja pewnie jak to przeczytam to dojdę do tego samego co czytałem i co zostało wymyślone kilka ładnych lat temu. Trochę mi się odechciewa czytać dalej ale będę uczciwy w stosunku do dyskutantów, ale teraz idę spać. Naprawdę. :-)
-- Marek Zibrow marek@zibrow.pl
W dniu 29 maja 2014 01:17 użytkownik Radoslaw Szkodzinski astralstorm@gmail.com napisał:
Zawiera dokładnie jedno trudne założenie: istnienie anonimowego kanału komunikacji do organizacji.
W tym przypadku możemy posłużyć się nieco staromodnym podejściem z MixMiniona... i bardzo długotrwałymi sesjami.
R.
General mailing list General@lists.hackerspace.pl https://lists.hackerspace.pl/mailman/listinfo/general
Masz rację, występuije w protokole "trusted server" T. Zatem znowu nic nie warte.
Zostaje może kryptosystem Chena, ale nie mogę się dokopać do szczegółów. (nie mam dostępu do tego journala)
R.
W dniu 29 maja 2014 00:10 użytkownik Robert Partyka bobson@bobson.pl napisał:
W dniu 2014-05-29 00:04, Marek Zibrow pisze:
Tu nie chodzi o bezpieczeństwo SZYFROWANIA lub ANONIMOWE SZYFROWANIE tylko o ANONIMOWĄ PUBLIKACJĘ z AUTORYZOWANEGO KRĘGU. Czy paniali wszyscy czy może pójdą po książki??? Zaczynam się kurcze irytować....
Dopiero teraz zaczynasz się irytować? Jak zobaczyłem "doplątywanie", "teleportację" i "2*n^2 tokenów" w kontekście zastosowania splątania kwantowego, o którym wspomniałeś, to nie wiedziałem, czy się zacząć śmiać czy płakać.
No masz rację nic tu po mnie. Pójdę się przespać. Odstresować. Miałem ciężki dzień. Jestem chyba za stary. Jakiś koleś wjechał mi w samochód bo zaciemniło mu się czerwone światło. Pewnie Darknet z martwych drzew przesłonił mu wizję. Naprawdę wszystkich pozdrawiam. Koledzy! Radosławie! Piotrze! Ogarnijcie się. Proszę...
Dnia czwartek, 29 maja 2014 00:04:54 Marek Zibrow pisze:
W dniu 28 maja 2014 23:53 użytkownik Piotr Pies Ostrowski
hackerspace@314es.pl napisał:
2014-05-28 23:19 GMT+02:00 Piotr Pies Ostrowski hackerspace@314es.pl:
A to algorytmy do głosowania elektronicznego nie są ogarnięte?
A jeśli są to zakładają, że komisja wyborcza nie wie komu wydała "kartę do głosowania"? No coś takiego... ;-D
No dokładnie, kwestia tylko by zamiast komunikatu "Głosuję na X" przekazać "Dodaję do puli klucz o wartości xyz". W ten sposób istnieje klucz który wiadomo, że należy do osoby uprawnionej ale nie wiadomo do kogo konkretnie (o ile działa algorytm od samego głosowania) a którym obywatel może się posługiwać w dyskusji.
Wiadomo, że należy do osoby uprawnionej? Zadaj sobie pytanie SKĄD TO WIADOMO.
Jak się załatwi kwestię kluczy to już chyba dalej nie ma problemu
Tu nie chodzi o bezpieczeństwo SZYFROWANIA lub ANONIMOWE SZYFROWANIE tylko o ANONIMOWĄ PUBLIKACJĘ z AUTORYZOWANEGO KRĘGU. Czy paniali wszyscy czy może pójdą po książki??? Zaczynam się kurcze irytować....
O, dziękuję. :)
Dokładnie. Szyfrowanie i anonimowe zapodanie samej podpisanej informacji to osobne problemy, które można rozwiązać oddzielnie (TOR je rozwiązuje oba w stopniu zupełnie zadowalającym).
Chodzi o podpisanie komunikatu w taki sposób, by: 1. wiadomo było, że użyty klucz należy do pewnej puli kluczy 2. nie wiadomo było, który to dokładnie klucz
Dnia środa, 28 maja 2014 23:34:34 Radoslaw Szkodzinski pisze:
2014-05-28 23:19 GMT+02:00 Piotr Pies Ostrowski hackerspace@314es.pl:
A to algorytmy do głosowania elektronicznego nie są ogarnięte? W takim przypadku wystarczyłoby, by obywatel zamiast podpisywać głos, podpisywał klucz stworzony przez siebie, a następnie posługiwał się tym kluczem w dyskusji?
Głosowanie to komunikacja 1:1, do tego jednorazowa i jednokierunkowa. (źródło głosu -> urna)
Rysio postuluje system N:N do dyskusji.
Trochę tak, ale nie musi być N:N w tym sensie, że cała dyskusja może odbywać się np. na portalu konsultacji społecznych miasta czy gminy. Więc *wymiana poglądów* byłaby N:N, ale komunikacja byłaby 1:1 (użytkownik:portal).
On 2014-05-28 19:09, Jaroslaw Gorny wrote:
Ale co to za różnica? W e-głosowaniu też chodzi o to, by mieć gwarancję, że dany głos został oddany przez osobę uprawnioną, z danego okręgu. A to czy "głos" polega na zaznaczeniu kratki przy nazwisku kandydata, czy przesłaniu kawałka swojej wypowiedzi w TXT / PDF, to przecież bez znaczenia.
Chyba, że czegoś ważnego nie rozumiem w tym co mówisz, co nie jest wykluczone ;)
A, śmieszna sytuacja w rodzinie w te wybory. Pani w komisji:
"Tyle osób mieszka na tym adresie, a tylko jedna się pojawia do głosowania? wstyd!"
Hej,
W dniu 2014-05-28 18:42, rysiek pisze:
- możliwość śledzenia wypowiedzi konkretnej osoby (identyfikowanej numerem, sumą kontrolną, pseudonimem, etc)
- ale nie chcemy technicznej możliwości ustalenia, który pseudonim do kogo należy.
Jeśli będzie jeden pseudonim/id/cokolwiek używany przy każdej wypowiedzi danej osoby jako podpis, to zbierając historyczne wypowiedzi istnieje coraz większe ryzyko utraty anonimowości.
pozdrowienia, BoBsoN
Szczerze mówiąc to dziwię się, że jeszcze to rozważacie. Jest to problem center-of-trust / set-of-trust. Set-of-trust jest możliwe, ale tylko pod wieloma warunkami: - jednoczesne wydanie certyfikatów/tokenów wszystkim uczestnikom dyskusji - jednoczesne opóźnienia transmisji dla wszystkich uczestników dyskusji - identyczność wszystkich certyfikatów/tokenów a tym samym niemożność zarządzania nimi co implikuje konieczność wymiany wszystkich certyfikatów/tokenów w momencie zgłoszenia przejęcia a zgłoszenie przejęcia może samo w sobie być działaniem typu "malicious" na co set-of-trust jest całkowicie nieodporny - UWAGA: konieczność pozostawania online podczas całej dyskusji wszystkich uczestników dyskusji (każde wyłącznie, awaria, opóźnienie powoduje stopniowy spadek zaufania do anonimowości) - długość trwania dyskusji sama w sobie powoduje spadek zaufania do anonimowści (to co powiedział BoBsoN) - na bazie logiki i teorii zbiorów można przeprowadzić dowód dlaczego to w praktyce nie zadziała (jak będę miał więcej czasu chętnie mogę się w to pobawić) - paradoks złotego środka (za duży set staje się stanowczo za bardzo niezarządzalny, za mały set staje się zbyt mało anonimowy)
Możliwości oczywiście istnieją głównie w... fizyce kwantowej. Jeszcze tak zaawansowanej elektroniki czy też optoelektroniki nie tworzymy niestety.
Powyższe jest przyczyną dlaczego nie zaimplementowano jeszcze praktycznie żadnej set-of-trust a wszystko praktycznie odbywa się na zasadzie center-of-trust (nawet jeśli jest to widespread center-of-trust jak bitcoin). Praktycznym rozwiązaniem jest niestety powierzenie naszego center-of-trust komuś komu obie strony trust że tego kogoś nie obchodzi wynik dyskusji.
-- Marek Zibrow marek@zibrow.pl
W dniu 28 maja 2014 22:59 użytkownik Robert Partyka bobson@bobson.pl napisał:
Hej,
W dniu 2014-05-28 18:42, rysiek pisze:
- możliwość śledzenia wypowiedzi konkretnej osoby (identyfikowanej
numerem, sumą kontrolną, pseudonimem, etc)
- ale nie chcemy technicznej możliwości ustalenia, który pseudonim do
kogo należy.
Jeśli będzie jeden pseudonim/id/cokolwiek używany przy każdej wypowiedzi danej osoby jako podpis, to zbierając historyczne wypowiedzi istnieje coraz większe ryzyko utraty anonimowości.
pozdrowienia, BoBsoN
General mailing list General@lists.hackerspace.pl https://lists.hackerspace.pl/mailman/listinfo/general
2014-05-28 23:15 GMT+02:00 Marek Zibrow marek@zibrow.pl:
Szczerze mówiąc to dziwię się, że jeszcze to rozważacie. Jest to problem center-of-trust / set-of-trust. Set-of-trust jest możliwe, ale tylko pod wieloma warunkami:
- jednoczesne wydanie certyfikatów/tokenów wszystkim uczestnikom dyskusji
- jednoczesne opóźnienia transmisji dla wszystkich uczestników dyskusji
Chcesz to robić odporne na traffic analysis. Jaki jest threat model tego systemu?
- identyczność wszystkich certyfikatów/tokenów a tym samym niemożność
zarządzania nimi co implikuje konieczność wymiany wszystkich certyfikatów/tokenów w momencie zgłoszenia przejęcia a zgłoszenie przejęcia może samo w sobie być działaniem typu "malicious" na co set-of-trust jest całkowicie nieodporny
To prawda, skradziony klucz szyfrujący gminy powoduje katastrofę.
- UWAGA: konieczność pozostawania online podczas całej dyskusji
wszystkich uczestników dyskusji (każde wyłącznie, awaria, opóźnienie powoduje stopniowy spadek zaufania do anonimowości)
To nie jest prawda, traffic analysis nie jest aż takie proste. Próbujesz wynaleźć MixMinion wersja broadcast?
- długość trwania dyskusji sama w sobie powoduje spadek zaufania do
anonimowści (to co powiedział BoBsoN)
Mowa o pseudonimowości, nie anonimowości.
- na bazie logiki i teorii zbiorów można przeprowadzić dowód dlaczego
to w praktyce nie zadziała (jak będę miał więcej czasu chętnie mogę się w to pobawić)
- paradoks złotego środka (za duży set staje się stanowczo za bardzo
niezarządzalny, za mały set staje się zbyt mało anonimowy)
Możliwości oczywiście istnieją głównie w... fizyce kwantowej.
Niby jakie? Masz taki wredny no-cloning theorem bardzo skutecznie niwelujący broadcasty.
W dniu 28 maja 2014 23:21 użytkownik Radoslaw Szkodzinski astralstorm@gmail.com napisał:
2014-05-28 23:15 GMT+02:00 Marek Zibrow marek@zibrow.pl:
Szczerze mówiąc to dziwię się, że jeszcze to rozważacie. Jest to problem center-of-trust / set-of-trust. Set-of-trust jest możliwe, ale tylko pod wieloma warunkami:
- jednoczesne wydanie certyfikatów/tokenów wszystkim uczestnikom dyskusji
- jednoczesne opóźnienia transmisji dla wszystkich uczestników dyskusji
Chcesz to robić odporne na traffic analysis. Jaki jest threat model tego systemu?
Czy ja coś takiego powiedziałem? Ja tylko wyraźnie daję Ci do zrozumienia, że traffic analisys a właściwie failure analysis dla systemu z małą liczbą użytkowników jest... banalnie prosty a dla systemu z dużą liczbą użytkowników oczywiście nie jest. Tylko, ze ten system z dużą liczbą użytkowników przestaje być praktyczny.
- identyczność wszystkich certyfikatów/tokenów a tym samym niemożność
zarządzania nimi co implikuje konieczność wymiany wszystkich certyfikatów/tokenów w momencie zgłoszenia przejęcia a zgłoszenie przejęcia może samo w sobie być działaniem typu "malicious" na co set-of-trust jest całkowicie nieodporny
To prawda, skradziony klucz szyfrujący gminy powoduje katastrofę.
- UWAGA: konieczność pozostawania online podczas całej dyskusji
wszystkich uczestników dyskusji (każde wyłącznie, awaria, opóźnienie powoduje stopniowy spadek zaufania do anonimowości)
To nie jest prawda, traffic analysis nie jest aż takie proste. Próbujesz wynaleźć MixMinion wersja broadcast?
Nie. TO JEST PRAWDA. Tylko próbujesz mi wmówić, że traffic analysis nie jest aż tak proste. Jeśli nawet się zgodzę, że nie jest tak proste to pozostaje wykonalne a więc jest to prawda. Chcę uniknac shitstormu. Napisałem o tym co jest faktem. Możemy się nie zgadzać co do trudności. Trudno.
- długość trwania dyskusji sama w sobie powoduje spadek zaufania do
anonimowści (to co powiedział BoBsoN)
Mowa o pseudonimowości, nie anonimowości.
Nie. Mowa o anonimowości. Wraz z upływem czasu można z coraz większym prawdopodobieństwem powiązać dane wypowiedzi z konkretną osoba której wydano certyfikat/token. Lista osób którym wydano cert/tok jest znana.
- na bazie logiki i teorii zbiorów można przeprowadzić dowód dlaczego
to w praktyce nie zadziała (jak będę miał więcej czasu chętnie mogę się w to pobawić)
- paradoks złotego środka (za duży set staje się stanowczo za bardzo
niezarządzalny, za mały set staje się zbyt mało anonimowy)
Możliwości oczywiście istnieją głównie w... fizyce kwantowej.
Niby jakie? Masz taki wredny no-cloning theorem bardzo skutecznie niwelujący broadcasty.
Kulą w płot. Stan splątany.
Pozdrawiam i proszę się na mnie nie wyżywać za rzeczowe napisanie prawdy. Rozwinę temat w sobotę. Nawet popełnię artykuł bo zagadnienie jest ciekawe.
2014-05-28 23:33 GMT+02:00 Marek Zibrow marek@zibrow.pl:
W dniu 28 maja 2014 23:21 użytkownik Radoslaw Szkodzinski astralstorm@gmail.com napisał:
2014-05-28 23:15 GMT+02:00 Marek Zibrow marek@zibrow.pl:
Szczerze mówiąc to dziwię się, że jeszcze to rozważacie. Jest to problem center-of-trust / set-of-trust. Set-of-trust jest możliwe, ale tylko pod wieloma warunkami:
- jednoczesne wydanie certyfikatów/tokenów wszystkim uczestnikom dyskusji
- jednoczesne opóźnienia transmisji dla wszystkich uczestników dyskusji
Chcesz to robić odporne na traffic analysis. Jaki jest threat model tego systemu?
Czy ja coś takiego powiedziałem? Ja tylko wyraźnie daję Ci do zrozumienia, że traffic analisys a właściwie failure analysis dla systemu z małą liczbą użytkowników jest... banalnie prosty a dla systemu z dużą liczbą użytkowników oczywiście nie jest. Tylko, ze ten system z dużą liczbą użytkowników przestaje być praktyczny.
- identyczność wszystkich certyfikatów/tokenów a tym samym niemożność
zarządzania nimi co implikuje konieczność wymiany wszystkich certyfikatów/tokenów w momencie zgłoszenia przejęcia a zgłoszenie przejęcia może samo w sobie być działaniem typu "malicious" na co set-of-trust jest całkowicie nieodporny
To prawda, skradziony klucz szyfrujący gminy powoduje katastrofę.
- UWAGA: konieczność pozostawania online podczas całej dyskusji
wszystkich uczestników dyskusji (każde wyłącznie, awaria, opóźnienie powoduje stopniowy spadek zaufania do anonimowości)
To nie jest prawda, traffic analysis nie jest aż takie proste. Próbujesz wynaleźć MixMinion wersja broadcast?
Nie. TO JEST PRAWDA. Tylko próbujesz mi wmówić, że traffic analysis nie jest aż tak proste.
Tak, oczywiście, gmina jest jednocześnie ISP i/lub nadzoruje każdego z osobna, aby patrzeć, kiedy wchodzi do domu. (To drugie jest prawie możliwe.)
Jeśli nawet się zgodzę, że nie jest tak proste to pozostaje wykonalne a więc jest to prawda.
Pozostaje, ale nadal nie ma tego w threat modelu. "Gmina" nie ma zasobów do takiej analizy. Co innego np. państwo lub przypadek, gdy wszystkie łącza internetowe są własnością tej gminy.
- długość trwania dyskusji sama w sobie powoduje spadek zaufania do
anonimowści (to co powiedział BoBsoN)
Mowa o pseudonimowości, nie anonimowości.
Nie. Mowa o anonimowości.
Taa, oczywiście dłuższy czas dyskusji z jednym kluczem zwiększa prawdopodobieństwo odkrycia *pseudonimu*. Im dłużej używasz tego samego *pseudonimu*, tym większa szansa na jego depseudonimizację.
Anonimowy oznacza taki, którego nie da się w żaden sposób powiązać z osobą. Dyskusja nigdy nie jest anonimowa, ponieważ istnieje analiza statystyczna treści oraz (w niektórych przypadkach) czasu wysłania. Może być pseudonimowa albo "deniable". (nie pamiętam polskiego odpowiednika)
Lista osób którym wydano cert/tok jest znana.
Tak, właśnie to jest główny problem. Zbiór możliwy jest raczej dość mały.
- na bazie logiki i teorii zbiorów można przeprowadzić dowód dlaczego
to w praktyce nie zadziała (jak będę miał więcej czasu chętnie mogę się w to pobawić)
- paradoks złotego środka (za duży set staje się stanowczo za bardzo
niezarządzalny, za mały set staje się zbyt mało anonimowy)
Możliwości oczywiście istnieją głównie w... fizyce kwantowej.
Niby jakie? Masz taki wredny no-cloning theorem bardzo skutecznie niwelujący broadcasty.
Kulą w płot. Stan splątany.
Musisz mieć 2*N^2 "tokenów" kwantowych, wszystkie ze sobą splątane. (Używamy teleportacji kwantowej. N = liczba uczestników.)
Nie możesz dodać nowej osoby do systemu, bo nie da się "doplątać" stanu.
Try harder.
Musisz mieć 2*N^2 "tokenów" kwantowych, wszystkie ze sobą splątane. (Używamy teleportacji kwantowej. N = liczba uczestników.)
Nie możesz dodać nowej osoby do systemu, bo nie da się "doplątać" stanu.
A kto powiedział, że postulat o jednoczesnym wydaniu przestaje obowiązywać? Pls don't even try. Zawsze mogę podzielić dyskusję na autoryzowane cząstkowo wypowiedzi a "system" tworzyć ad-hoc do każdej wypowiedzi autoryzując taką ilość uczestników jaka jest potrzebna.
Niezależnie od wszystkich podanych ewentualnych rozwiązań pozostaje jeszcze problem dotyczący mniej więcej gry w dupniaka w zamkniętym pokoju i kwestia prawdopodobieństwa.
Po co rozważać w ogóle tak niepraktyczne działanie skoro rysiowi chodzi o praktyczne zastosowanie. Jeśli potrzebą jest działanie podałem, IMHO, najlepsze rozwiązanie czyli "eksport" centrum uwierzytelniania. Taki PayPal mniej więcej.
---- Wł. Śr, 28 maj 2014 17:41:11 +0200 rysiek napisał(a) ----
Cześć,
mam rokminkę -- mam wrażenie, że to powinno być możliwe, ale nie mogę w tej chwili ogarnąć, czy faktycznie jest, i czy przypadkiem jakiś soft już tego nie potrafi.
O co biega.
Czy możliwy jest do zaimplementowania system, w którym:
- obywatel idzie do urzędu/instytucji/trusted third party, tam generowany
jest para kluczy, certyfikat, podpis cyfrowy, cokolwiek -- jakiś token kryptograficzny;
- obywatel chce wziąć udział w konsultacjach społecznych; w tym celu musi
udowodnić, że ma prawo wziąć w nich udział, więc używa tokenu, ale...
- …w taki sposób, że urząd może stwierdzić, że faktycznie został użyty wydany
przez ten urząd token, ale
- ...tenże urząd nie ma żadnej możliwości ustalenia, który dokładnie token
został użyty (czyli: który obywatel wygłosił dany głos).
Słowem chodzi o system, w którym jesteśmy w stanie zweryfikować, że coś zostało podpisane kluczem jednej z osób z jakiejś grupy, ale jednocześnie nie jesteśmy w stanie sprawdzić, która to dokładnie osoba.
Jest coś takiego jak "attribute certificates":
http://courses.cs.vt.edu/~cs5204/fall02/Papers/Security/AttributeCertificate...
z tego, co czytam jeżeli potraktujemy możliwość zabrania głosu w konsultacji X jako wpis w wielkiej wyobrażonej ACL to możnaby to wykorzystać. Wygląda na to, że działa w oparciu o x509, więc może być łatwiejsze do przełknięcia przez rządowe systemy IT niż jakieś lewackie openPGP dla unixowców brodaczy.
Dnia środa, 28 maja 2014 21:57:59 enki pisze:
---- Wł. Śr, 28 maj 2014 17:41:11 +0200 rysiek napisał(a) ----
Cześć,
mam rokminkę -- mam wrażenie, że to powinno być możliwe, ale nie mogę w tej chwili ogarnąć, czy faktycznie jest, i czy przypadkiem jakiś soft już tego nie potrafi.
O co biega.
Czy możliwy jest do zaimplementowania system, w którym:
- obywatel idzie do urzędu/instytucji/trusted third party, tam generowany
jest para kluczy, certyfikat, podpis cyfrowy, cokolwiek -- jakiś token kryptograficzny;
- obywatel chce wziąć udział w konsultacjach społecznych; w tym celu musi
udowodnić, że ma prawo wziąć w nich udział, więc używa tokenu, ale...
- …w taki sposób, że urząd może stwierdzić, że faktycznie został użyty
wydany przez ten urząd token, ale
- ...tenże urząd nie ma żadnej możliwości ustalenia, który dokładnie token
został użyty (czyli: który obywatel wygłosił dany głos).
Słowem chodzi o system, w którym jesteśmy w stanie zweryfikować, że coś zostało podpisane kluczem jednej z osób z jakiejś grupy, ale jednocześnie nie jesteśmy w stanie sprawdzić, która to dokładnie osoba.
Jest coś takiego jak "attribute certificates":
http://courses.cs.vt.edu/~cs5204/fall02/Papers/Security/AttributeCertificate s.pdf
z tego, co czytam jeżeli potraktujemy możliwość zabrania głosu w konsultacji X jako wpis w wielkiej wyobrażonej ACL to możnaby to wykorzystać. Wygląda na to, że działa w oparciu o x509, więc może być łatwiejsze do przełknięcia przez rządowe systemy IT niż jakieś lewackie openPGP dla unixowców brodaczy.
Pyszne, dzięki!
2014-05-28 17:41 GMT+02:00 rysiek rysiek@hackerspace.pl:
Cześć,
mam rokminkę -- mam wrażenie, że to powinno być możliwe, ale nie mogę w tej chwili ogarnąć, czy faktycznie jest, i czy przypadkiem jakiś soft już tego nie potrafi.
O co biega.
Czy możliwy jest do zaimplementowania system, w którym:
- obywatel idzie do urzędu/instytucji/trusted third party, tam generowany
jest para kluczy, certyfikat, podpis cyfrowy, cokolwiek -- jakiś token kryptograficzny;
- obywatel chce wziąć udział w konsultacjach społecznych; w tym celu musi
udowodnić, że ma prawo wziąć w nich udział, więc używa tokenu, ale...
- …w taki sposób, że urząd może stwierdzić, że faktycznie został użyty wydany
przez ten urząd token, ale
- ...tenże urząd nie ma żadnej możliwości ustalenia, który dokładnie token
został użyty (czyli: który obywatel wygłosił dany głos).
1. Urząd generuje klucz prywatny i publiczny gminy. Urząd wysyła klucz publiczny gminy do użyszkodników. Rzeczoni użytkownicy trzymają ten klucz jako tajny. Klucz prywatny jest jawny i dostępny, aby każdy mógł zweryfikować podpis.
ad. 2,3,4. Obywatel używa klucza publicznego i szyfruje nim jednorazowy/wielorazowy klucz symetryczny z noncją. Używa rzeczonego klucza symetrycznego tyle razy, ile potrzebuje przechować pseudonim.
Prawie jak GPG, tylko PKI zastosowane odwrotnie.
R.
Uważałbym na kolizje przy tym rozwiązaniu.
2014-05-28 23:09 GMT+02:00 Radoslaw Szkodzinski astralstorm@gmail.com:
2014-05-28 17:41 GMT+02:00 rysiek rysiek@hackerspace.pl:
Cześć,
mam rokminkę -- mam wrażenie, że to powinno być możliwe, ale nie mogę w
tej
chwili ogarnąć, czy faktycznie jest, i czy przypadkiem jakiś soft już
tego nie
potrafi.
O co biega.
Czy możliwy jest do zaimplementowania system, w którym:
- obywatel idzie do urzędu/instytucji/trusted third party, tam
generowany
jest para kluczy, certyfikat, podpis cyfrowy, cokolwiek -- jakiś token kryptograficzny;
- obywatel chce wziąć udział w konsultacjach społecznych; w tym celu
musi
udowodnić, że ma prawo wziąć w nich udział, więc używa tokenu, ale...
- …w taki sposób, że urząd może stwierdzić, że faktycznie został użyty
wydany
przez ten urząd token, ale
- ...tenże urząd nie ma żadnej możliwości ustalenia, który dokładnie
token
został użyty (czyli: który obywatel wygłosił dany głos).
- Urząd generuje klucz prywatny i publiczny gminy.
Urząd wysyła klucz publiczny gminy do użyszkodników. Rzeczoni użytkownicy trzymają ten klucz jako tajny. Klucz prywatny jest jawny i dostępny, aby każdy mógł zweryfikować podpis.
ad. 2,3,4. Obywatel używa klucza publicznego i szyfruje nim jednorazowy/wielorazowy klucz symetryczny z noncją. Używa rzeczonego klucza symetrycznego tyle razy, ile potrzebuje przechować pseudonim.
Prawie jak GPG, tylko PKI zastosowane odwrotnie.
R.
General mailing list General@lists.hackerspace.pl https://lists.hackerspace.pl/mailman/listinfo/general
Jest problem w tym schemacie. Każdy z członków grupy może się podszyć pod innego.
Zatem zamiast klucza symetrycznego używamy po raz kolejny odwróconej pary klucz prywatny/publiczny, gdzie ponownie klucz publiczny jest tajny. Ta para istnieje tak długo, jak pseudonim.
Dnia środa, 28 maja 2014 23:15:54 Radoslaw Szkodzinski pisze:
Jest problem w tym schemacie. Każdy z członków grupy może się podszyć pod innego.
Zatem zamiast klucza symetrycznego używamy po raz kolejny odwróconej pary klucz prywatny/publiczny, gdzie ponownie klucz publiczny jest tajny. Ta para istnieje tak długo, jak pseudonim.
Rozkminiam. Wydaje się robić sens, ale może czegoś nie widzę. Dzięki serdeczne za food for thought.
Elo,
dzięki wszystkim za odpowiedzi! Nie dam rady ich wszystkich ogarnąć dziś, nie spodziewałem się takiego zainteresowania tematem! Jutro doczytam wątek i spłodzę krótkie wyjaśnienie, skąd pytanie w ogóle się wzięło. :)
Tymczasem!
On Wed, May 28, 2014 at 05:41:11PM +0200, rysiek wrote:
Cześć,
mam rokminkę -- mam wrażenie, że to powinno być możliwe, ale nie mogę w tej chwili ogarnąć, czy faktycznie jest, i czy przypadkiem jakiś soft już tego nie potrafi.
O co biega.
Czy możliwy jest do zaimplementowania system, w którym:
- obywatel idzie do urzędu/instytucji/trusted third party, tam generowany
jest para kluczy, certyfikat, podpis cyfrowy, cokolwiek -- jakiś token kryptograficzny;
- obywatel chce wziąć udział w konsultacjach społecznych; w tym celu musi
udowodnić, że ma prawo wziąć w nich udział, więc używa tokenu, ale...
- …w taki sposób, że urząd może stwierdzić, że faktycznie został użyty wydany
przez ten urząd token, ale
- ...tenże urząd nie ma żadnej możliwości ustalenia, który dokładnie token
został użyty (czyli: który obywatel wygłosił dany głos).
Słowem chodzi o system, w którym jesteśmy w stanie zweryfikować, że coś zostało podpisane kluczem jednej z osób z jakiejś grupy, ale jednocześnie nie jesteśmy w stanie sprawdzić, która to dokładnie osoba.
Wygenerować losowe klucze gpg na smartcardach, rozdawać je ludziom na zasadzie "tu się podpisz, że odebrałeś smartcarda, a tam masz szklaną miskę ze smartcardami, wylosuj sobie jeden" (urząd nie zapisuje który sobie wylosowałeś). Oczywiście uprzednio - przed "losowaniem" - podpisać te klucze, kluczami instytucji. Czy może jest w tym jakiś problem którego nie widzę?
Dnia czwartek, 29 maja 2014 10:11:15 arachnist@i.am-a.cat pisze:
Wygenerować losowe klucze gpg na smartcardach, rozdawać je ludziom na zasadzie "tu się podpisz, że odebrałeś smartcarda, a tam masz szklaną miskę ze smartcardami, wylosuj sobie jeden" (urząd nie zapisuje który sobie wylosowałeś). Oczywiście uprzednio - przed "losowaniem" - podpisać te klucze, kluczami instytucji. Czy może jest w tym jakiś problem którego nie widzę?
O, to jest rozwinięcie pomysłu z anonimowym kluczem wydawanym w urzędzie, zaproponowanym przez CyberKillera -- fizyczne losowanie rozwiązuje problem "a my po cichu zapiszemy, kto ma który klucz".
Dobry punkt wyjścia, dzięki.
Dodatkowa rozkminka (które przy tym systemie nie zadziałają):
- czy da się zrobić tak, by nawet, gdyby urząd/attacker/bad guy wiedział, kto ma który klucz, nadal nie był w stanie ustalić czy ta podpisana wypowiedź została podpisana tym konkretnym kluczem?
czyli plausible deniability nawet w sytuacji zdobycia danego smartcarda przez urząd.
I to jest właściwie postawione pytanie, na które musimy odpowiedzieć. Rozdanie ludziom kluczy i "zapomnienie" kto ma który naprawde nie wydaje się dostatecznie bezpiecznym wyjściem, ryśku.
Zegar
2014-05-29 10:21 GMT+02:00 rysiek rysiek@hackerspace.pl:
Dnia czwartek, 29 maja 2014 10:11:15 arachnist@i.am-a.cat pisze:
Wygenerować losowe klucze gpg na smartcardach, rozdawać je ludziom na zasadzie "tu się podpisz, że odebrałeś smartcarda, a tam masz szklaną miskę ze smartcardami, wylosuj sobie jeden" (urząd nie zapisuje który sobie wylosowałeś). Oczywiście uprzednio - przed "losowaniem" - podpisać te klucze, kluczami instytucji. Czy może jest w tym jakiś problem którego nie widzę?
O, to jest rozwinięcie pomysłu z anonimowym kluczem wydawanym w urzędzie, zaproponowanym przez CyberKillera -- fizyczne losowanie rozwiązuje problem "a my po cichu zapiszemy, kto ma który klucz".
Dobry punkt wyjścia, dzięki.
Dodatkowa rozkminka (które przy tym systemie nie zadziałają):
- czy da się zrobić tak, by nawet, gdyby urząd/attacker/bad guy wiedział,
kto ma który klucz, nadal nie był w stanie ustalić czy ta podpisana wypowiedź została podpisana tym konkretnym kluczem?
czyli plausible deniability nawet w sytuacji zdobycia danego smartcarda przez urząd.
-- Pozdr rysiek _______________________________________________ General mailing list General@lists.hackerspace.pl https://lists.hackerspace.pl/mailman/listinfo/general
Dnia czwartek, 29 maja 2014 10:29:17 Paweł Zegartowski pisze:
I to jest właściwie postawione pytanie, na które musimy odpowiedzieć. Rozdanie ludziom kluczy i "zapomnienie" kto ma który naprawde nie wydaje się dostatecznie bezpiecznym wyjściem, ryśku.
No nie jest, ale "losowanie" nie wymaga "zapomnienia". ;)
W dniu 29 maja 2014 10:34 użytkownik rysiek rysiek@hackerspace.pl napisał:
Dnia czwartek, 29 maja 2014 10:29:17 Paweł Zegartowski pisze:
I to jest właściwie postawione pytanie, na które musimy odpowiedzieć. Rozdanie ludziom kluczy i "zapomnienie" kto ma który naprawde nie wydaje się dostatecznie bezpiecznym wyjściem, ryśku.
No nie jest, ale "losowanie" nie wymaga "zapomnienia". ;)
Ale każda utrata przedmiotu losowania (kradzież, zagubienie, zniszczenie) wymaga powtórzenia losowania przez wszystkich w oparciu o nowostworzone przedmioty (smartcardy czy cokolwiek, po prostu fizyczne tokeny). Czyni to system niepraktycznym chyba, że przyjmiemy za obojętne albo pomijalne, że w systemie działają nieuprawnieni użytkownicy.
Fizyczne tokeny utrudniają też łatwe zwiększenie liczby kluczy. No i oczywiscie podnoszą koszta.
2014-05-29 10:43 GMT+02:00 Marek Zibrow marek@zibrow.pl:
W dniu 29 maja 2014 10:34 użytkownik rysiek rysiek@hackerspace.pl napisał:
Dnia czwartek, 29 maja 2014 10:29:17 Paweł Zegartowski pisze:
I to jest właściwie postawione pytanie, na które musimy odpowiedzieć. Rozdanie ludziom kluczy i "zapomnienie" kto ma który naprawde nie wydaje się dostatecznie bezpiecznym wyjściem, ryśku.
No nie jest, ale "losowanie" nie wymaga "zapomnienia". ;)
Ale każda utrata przedmiotu losowania (kradzież, zagubienie, zniszczenie) wymaga powtórzenia losowania przez wszystkich w oparciu o nowostworzone przedmioty (smartcardy czy cokolwiek, po prostu fizyczne tokeny). Czyni to system niepraktycznym chyba, że przyjmiemy za obojętne albo pomijalne, że w systemie działają nieuprawnieni użytkownicy.
General mailing list General@lists.hackerspace.pl https://lists.hackerspace.pl/mailman/listinfo/general
W dniu 29 maja 2014 10:47 użytkownik Paweł Zegartowski pzegar@gmail.com napisał:
Fizyczne tokeny utrudniają też łatwe zwiększenie liczby kluczy. No i oczywiscie podnoszą koszta.
Problem z wirtualnymi jest niestety podobny (plus parę innych związanych z ich tworzeniem). Niestety każde zgłoszenie utraty tokenu to powtórna generacja wszystkiego dla wszystkich. Oczywiście softtoken jest tani, można nawet stwierdzić, że bezpłatny, tylko co z tego, kiedy ponowne losowanie wszystkich tokenów (z utopijnym założeniem, że nikt nie rejestruje pobrania softtokena ze storage'u) jest niemal równie niepraktyczne jak ponowne losowanie fizycznych smartcard. Dodatkowo powtórzę jeszcze raz moją tezę, że system taki jest kompletnie nieodporny na złośliwe zgłoszenia utraty. Naprawdę nie mam ochoty nikogo onieśmielać bo jak wiadomo należy atakować problemy i szukać nowych rozwiązań ale wydaje mi się, że to było już parę razy przerabiane a sam rynek udowadnia dlaczego to nie działa... Stąd oprócz zapotrzebowania rysia postawiłbym pytanie:
Jak zrealizować to za pomocą typowego center-of-trust tak, żeby wilk był syty i owca cała?
Zgniły kompromis? Pewnie tak. Ale to jak z dzieleniem przez 0. Czy dyskusję można poprowadzić także w tym kierunku? Rysiu?
Pojadę "teorią" dlaczego uważam sprawę za z góry przegraną i mam nadzieję, że ktoś to zrozumie i przestaniemy przynajmniej powtarzać podstawowe błędy (matko jak ja nie lubię być malkontentem, ale muszę): Wszystkie znane mi systemy set-of-trust działają w przestrzeni zaufania gdzie każdy element setu jest znany wszystkim pozostałym i w każdej chwili wywoływalny. Set-of-trust w przestrzeni niezaufanej nie sprawdza się. Nie dlatego, że nie da się tego stworzyć. Tylko dlatego, że każde usunięcie elementu, brak dostępu do elementu, dodanie elementu, powoduje że set-of-trust staję się nietrust.
On 2014-05-29 13:14, Marek Zibrow wrote:
W dniu 29 maja 2014 10:47 użytkownik Paweł Zegartowski pzegar@gmail.com napisał:
Fizyczne tokeny utrudniają też łatwe zwiększenie liczby kluczy. No i oczywiscie podnoszą koszta.
Problem z wirtualnymi jest niestety podobny (plus parę innych związanych z ich tworzeniem). Niestety każde zgłoszenie utraty tokenu to powtórna generacja wszystkiego dla wszystkich. Oczywiście softtoken jest tani, można nawet stwierdzić, że bezpłatny, tylko co z tego, kiedy ponowne losowanie wszystkich tokenów (z utopijnym założeniem, że nikt nie rejestruje pobrania softtokena ze storage'u) jest niemal równie niepraktyczne jak ponowne losowanie fizycznych smartcard. Dodatkowo powtórzę jeszcze raz moją tezę, że system taki jest kompletnie nieodporny na złośliwe zgłoszenia utraty. Naprawdę nie mam ochoty nikogo onieśmielać bo jak wiadomo należy atakować problemy i szukać nowych rozwiązań ale wydaje mi się, że to było już parę razy przerabiane a sam rynek udowadnia dlaczego to nie działa... Stąd oprócz zapotrzebowania rysia postawiłbym pytanie:
Jak zrealizować to za pomocą typowego center-of-trust tak, żeby wilk był syty i owca cała?
Zgniły kompromis? Pewnie tak. Ale to jak z dzieleniem przez 0. Czy dyskusję można poprowadzić także w tym kierunku? Rysiu?
Pojadę "teorią" dlaczego uważam sprawę za z góry przegraną i mam nadzieję, że ktoś to zrozumie i przestaniemy przynajmniej powtarzać podstawowe błędy (matko jak ja nie lubię być malkontentem, ale muszę): Wszystkie znane mi systemy set-of-trust działają w przestrzeni zaufania gdzie każdy element setu jest znany wszystkim pozostałym i w każdej chwili wywoływalny. Set-of-trust w przestrzeni niezaufanej nie sprawdza się. Nie dlatego, że nie da się tego stworzyć. Tylko dlatego, że każde usunięcie elementu, brak dostępu do elementu, dodanie elementu, powoduje że set-of-trust staję się nietrust.
Ja bym poszedł w stronę ograniczenia strat.
Ponieważ ilość postów spod każdego klucza prowadzi do deanonimizacji w określonym czasie opisanym zachowaniem uzytkownika(od analizy danych po analizę semantyczną), trzeba te klucze generować ponownie co jakiś czas tak czy inaczej, więc powinny one być generowane per-project albo per-year albo coś.
Dodatkowa zmienna to generowanie kluczy jeśli zostanie zgłoszone zagubienie lub kradzieź ich 30%. "tough life bro, you don't lose your kids, your car, your money, I think you can keep a card - if not now, then maybe on the 2nd time".
Można stopień utraty ograniczyć losowaniem kilku powiązanych kluczy (jeden token, kilka kluczy. karta snap-off czy coś) i upewnieniem się ze zostanę rozmieszczone w różnych partiach ubrania delikwenta (torba, kieszeń, kurtka, whatevs). (za każdym razem jak myślę że coś jest owerkilem na głupotę ludzką, ludzkość mnie zaskakuje)
Jeżeli user jest znany z imienia i nazwiska (ale nie tokenu) to w przypadku faktycznej fizycznej utraty zgłasza ją i prosi o unieważnienie postów po określonej dacie zagubienia. Or not.
tl;dr: jeżeli utrata klucza jest problemem, trzeba doprowadzić do sytuacji w której ta utrata będzie mało prawdopodobna.
W dniu 29 maja 2014 13:46 użytkownik spin@hackerspace.pl napisał:
On 2014-05-29 13:14, Marek Zibrow wrote:
W dniu 29 maja 2014 10:47 użytkownik Paweł Zegartowski pzegar@gmail.com napisał:
Fizyczne tokeny utrudniają też łatwe zwiększenie liczby kluczy. No i oczywiscie podnoszą koszta.
Problem z wirtualnymi jest niestety podobny (plus parę innych związanych z ich tworzeniem). Niestety każde zgłoszenie utraty tokenu to powtórna generacja wszystkiego dla wszystkich. Oczywiście softtoken jest tani, można nawet stwierdzić, że bezpłatny, tylko co z tego, kiedy ponowne losowanie wszystkich tokenów (z utopijnym założeniem, że nikt nie rejestruje pobrania softtokena ze storage'u) jest niemal równie niepraktyczne jak ponowne losowanie fizycznych smartcard. Dodatkowo powtórzę jeszcze raz moją tezę, że system taki jest kompletnie nieodporny na złośliwe zgłoszenia utraty. Naprawdę nie mam ochoty nikogo onieśmielać bo jak wiadomo należy atakować problemy i szukać nowych rozwiązań ale wydaje mi się, że to było już parę razy przerabiane a sam rynek udowadnia dlaczego to nie działa... Stąd oprócz zapotrzebowania rysia postawiłbym pytanie:
Jak zrealizować to za pomocą typowego center-of-trust tak, żeby wilk był syty i owca cała?
Zgniły kompromis? Pewnie tak. Ale to jak z dzieleniem przez 0. Czy dyskusję można poprowadzić także w tym kierunku? Rysiu?
Pojadę "teorią" dlaczego uważam sprawę za z góry przegraną i mam nadzieję, że ktoś to zrozumie i przestaniemy przynajmniej powtarzać podstawowe błędy (matko jak ja nie lubię być malkontentem, ale muszę): Wszystkie znane mi systemy set-of-trust działają w przestrzeni zaufania gdzie każdy element setu jest znany wszystkim pozostałym i w każdej chwili wywoływalny. Set-of-trust w przestrzeni niezaufanej nie sprawdza się. Nie dlatego, że nie da się tego stworzyć. Tylko dlatego, że każde usunięcie elementu, brak dostępu do elementu, dodanie elementu, powoduje że set-of-trust staję się nietrust.
Ja bym poszedł w stronę ograniczenia strat.
Ponieważ ilość postów spod każdego klucza prowadzi do deanonimizacji w określonym czasie opisanym zachowaniem uzytkownika(od analizy danych po analizę semantyczną), trzeba te klucze generować ponownie co jakiś czas tak czy inaczej, więc powinny one być generowane per-project albo per-year albo coś.
Dodatkowa zmienna to generowanie kluczy jeśli zostanie zgłoszone zagubienie lub kradzieź ich 30%. "tough life bro, you don't lose your kids, your car, your money, I think you can keep a card - if not now, then maybe on the 2nd time".
Można stopień utraty ograniczyć losowaniem kilku powiązanych kluczy (jeden token, kilka kluczy. karta snap-off czy coś) i upewnieniem się ze zostanę rozmieszczone w różnych partiach ubrania delikwenta (torba, kieszeń, kurtka, whatevs). (za każdym razem jak myślę że coś jest owerkilem na głupotę ludzką, ludzkość mnie zaskakuje)
Jeżeli user jest znany z imienia i nazwiska (ale nie tokenu) to w przypadku faktycznej fizycznej utraty zgłasza ją i prosi o unieważnienie postów po określonej dacie zagubienia. Or not.
tl;dr: jeżeli utrata klucza jest problemem, trzeba doprowadzić do sytuacji w której ta utrata będzie mało prawdopodobna.
Bardzo sensowne to co powiedziałeś i popieram w całej rozciągłości. +1
Dnia czwartek, 29 maja 2014 13:14:58 Marek Zibrow pisze:
W dniu 29 maja 2014 10:47 użytkownik Paweł Zegartowski
pzegar@gmail.com napisał:
Fizyczne tokeny utrudniają też łatwe zwiększenie liczby kluczy. No i oczywiscie podnoszą koszta.
Problem z wirtualnymi jest niestety podobny (plus parę innych związanych z ich tworzeniem). Niestety każde zgłoszenie utraty tokenu to powtórna generacja wszystkiego dla wszystkich. Oczywiście softtoken jest tani, można nawet stwierdzić, że bezpłatny, tylko co z tego, kiedy ponowne losowanie wszystkich tokenów (z utopijnym założeniem, że nikt nie rejestruje pobrania softtokena ze storage'u) jest niemal równie niepraktyczne jak ponowne losowanie fizycznych smartcard. Dodatkowo powtórzę jeszcze raz moją tezę, że system taki jest kompletnie nieodporny na złośliwe zgłoszenia utraty. Naprawdę nie mam ochoty nikogo onieśmielać bo jak wiadomo należy atakować problemy i szukać nowych rozwiązań ale wydaje mi się, że to było już parę razy przerabiane a sam rynek udowadnia dlaczego to nie działa... Stąd oprócz zapotrzebowania rysia postawiłbym pytanie:
Jak zrealizować to za pomocą typowego center-of-trust tak, żeby wilk był syty i owca cała?
Zgniły kompromis? Pewnie tak. Ale to jak z dzieleniem przez 0. Czy dyskusję można poprowadzić także w tym kierunku? Rysiu?
Pojadę "teorią" dlaczego uważam sprawę za z góry przegraną i mam nadzieję, że ktoś to zrozumie i przestaniemy przynajmniej powtarzać podstawowe błędy (matko jak ja nie lubię być malkontentem, ale muszę): Wszystkie znane mi systemy set-of-trust działają w przestrzeni zaufania gdzie każdy element setu jest znany wszystkim pozostałym i w każdej chwili wywoływalny. Set-of-trust w przestrzeni niezaufanej nie sprawdza się. Nie dlatego, że nie da się tego stworzyć. Tylko dlatego, że każde usunięcie elementu, brak dostępu do elementu, dodanie elementu, powoduje że set-of-trust staję się nietrust.
A czy możesz zalinkować do jakichś materiałów dotyczących set-of-trust? Bo ja chciałbym móc poznać ten temat głębiej, na przykład.
Oczywiście postaram się o takie linki chociaż prędzej poradziłbym ci literaturę. Też ci ją zresztą podam ale w sobotę bo jestem w ruchu że tak powiem. Zagadnieniami SoT i CoT zajmowałem się na studiach i w pracy jakieś 6 lat temu stąd mój bardzo sceptyczny stosunek do możliwości uzyskania rozwiązania o jakim marzysz. I żeby było jasne strasznie chcę się pomylić tylko że w trakcie dyskusji parę razy zahaczono już o przysłowiową kwadraturę koła. 29 maj 2014 16:35 "rysiek" rysiek@hackerspace.pl napisał(a):
Dnia czwartek, 29 maja 2014 13:14:58 Marek Zibrow pisze:
W dniu 29 maja 2014 10:47 użytkownik Paweł Zegartowski
pzegar@gmail.com napisał:
Fizyczne tokeny utrudniają też łatwe zwiększenie liczby kluczy. No i oczywiscie podnoszą koszta.
Problem z wirtualnymi jest niestety podobny (plus parę innych związanych z ich tworzeniem). Niestety każde zgłoszenie utraty tokenu to powtórna generacja wszystkiego dla wszystkich. Oczywiście softtoken jest tani, można nawet stwierdzić, że bezpłatny, tylko co z tego, kiedy ponowne losowanie wszystkich tokenów (z utopijnym założeniem, że nikt nie rejestruje pobrania softtokena ze storage'u) jest niemal równie niepraktyczne jak ponowne losowanie fizycznych smartcard. Dodatkowo powtórzę jeszcze raz moją tezę, że system taki jest kompletnie nieodporny na złośliwe zgłoszenia utraty. Naprawdę nie mam ochoty nikogo onieśmielać bo jak wiadomo należy atakować problemy i szukać nowych rozwiązań ale wydaje mi się, że to było już parę razy przerabiane a sam rynek udowadnia dlaczego to nie działa... Stąd oprócz zapotrzebowania rysia postawiłbym pytanie:
Jak zrealizować to za pomocą typowego center-of-trust tak, żeby wilk był syty i owca cała?
Zgniły kompromis? Pewnie tak. Ale to jak z dzieleniem przez 0. Czy dyskusję można poprowadzić także w tym kierunku? Rysiu?
Pojadę "teorią" dlaczego uważam sprawę za z góry przegraną i mam nadzieję, że ktoś to zrozumie i przestaniemy przynajmniej powtarzać podstawowe błędy (matko jak ja nie lubię być malkontentem, ale muszę): Wszystkie znane mi systemy set-of-trust działają w przestrzeni zaufania gdzie każdy element setu jest znany wszystkim pozostałym i w każdej chwili wywoływalny. Set-of-trust w przestrzeni niezaufanej nie sprawdza się. Nie dlatego, że nie da się tego stworzyć. Tylko dlatego, że każde usunięcie elementu, brak dostępu do elementu, dodanie elementu, powoduje że set-of-trust staję się nietrust.
A czy możesz zalinkować do jakichś materiałów dotyczących set-of-trust? Bo ja chciałbym móc poznać ten temat głębiej, na przykład.
-- Pozdr rysiek _______________________________________________ General mailing list General@lists.hackerspace.pl https://lists.hackerspace.pl/mailman/listinfo/general
W dniu 29 maja 2014 10:11 użytkownik arachnist@i.am-a.cat napisał:
On Wed, May 28, 2014 at 05:41:11PM +0200, rysiek wrote:
Cześć,
mam rokminkę -- mam wrażenie, że to powinno być możliwe, ale nie mogę w tej chwili ogarnąć, czy faktycznie jest, i czy przypadkiem jakiś soft już tego nie potrafi.
O co biega.
Czy możliwy jest do zaimplementowania system, w którym:
- obywatel idzie do urzędu/instytucji/trusted third party, tam generowany
jest para kluczy, certyfikat, podpis cyfrowy, cokolwiek -- jakiś token kryptograficzny;
- obywatel chce wziąć udział w konsultacjach społecznych; w tym celu musi
udowodnić, że ma prawo wziąć w nich udział, więc używa tokenu, ale...
- …w taki sposób, że urząd może stwierdzić, że faktycznie został użyty wydany
przez ten urząd token, ale
- ...tenże urząd nie ma żadnej możliwości ustalenia, który dokładnie token
został użyty (czyli: który obywatel wygłosił dany głos).
Słowem chodzi o system, w którym jesteśmy w stanie zweryfikować, że coś zostało podpisane kluczem jednej z osób z jakiejś grupy, ale jednocześnie nie jesteśmy w stanie sprawdzić, która to dokładnie osoba.
Wygenerować losowe klucze gpg na smartcardach, rozdawać je ludziom na zasadzie "tu się podpisz, że odebrałeś smartcarda, a tam masz szklaną miskę ze smartcardami, wylosuj sobie jeden" (urząd nie zapisuje który sobie wylosowałeś). Oczywiście uprzednio - przed "losowaniem" - podpisać te klucze, kluczami instytucji. Czy może jest w tym jakiś problem którego nie widzę?
Mhm, Jest. I to spory. Przychodzę i mówię, że ktoś mi ukradł smartcard co implikuje, że wszyscy muszą natychmiast przyjść po nowe smartcardy. Pisałem o tym.
-
"Łukasz \"Cyber Killer\" Korpalski " -
antoszka -
arachnist＠i.am-a.cat -
enki -
Jakub Kramarz -
Jaroslaw Gorny -
Marek Zibrow -
Michal Andrzejczak -
Paweł Zegartowski -
piorek -
Piotr Pies Ostrowski -
Piotr Radosz -
Radoslaw Szkodzinski -
Robert Partyka -
rysiek -
spin＠hackerspace.pl -
Wiktor Przybylski -
Łukasz Dubiel