Comments 88
Вся суть топика во фразе «необходимо чтобы РОИ генерировал специальный проверочный код, но не содержащий личной информации пользователя. Список таких кодов должен быть доступен в общем пользовании». Эта мысль и так встречается в исходном топике и комментариях.
Все остальное — детали реализации, коих можно придумать сколько угодно, и делать топик на каждую нет необходимости. Так что статья не несет како-либо ценности.
Все остальное — детали реализации, коих можно придумать сколько угодно, и делать топик на каждую нет необходимости. Так что статья не несет како-либо ценности.
Немного ниже дан ответ, если коротко то:
Да, я позже тоже увидел похожие предложения. Но даже если кто то сказал что надо использовать ЭЦП (и верно сказал), то остается вопрос КАК именно....(cut) я предложил свое детальное решение — как должен выглядеть проверочный вектор, и что в него должно быть включено. Мог конечно где то ошибиться, но пока я ошибки не вижу, нужен взгляд со стороны.
Да, я позже тоже увидел похожие предложения. Но даже если кто то сказал что надо использовать ЭЦП (и верно сказал), то остается вопрос КАК именно....(cut) я предложил свое детальное решение — как должен выглядеть проверочный вектор, и что в него должно быть включено. Мог конечно где то ошибиться, но пока я ошибки не вижу, нужен взгляд со стороны.
Всё это хорошо, только вот функция отзыва голоса вчера была окончательно отключена: www.roi.ru/news/51/
А без неё почти прозрачный контроль достигается простым мониторингом неубывания количества голосов.
А без неё почти прозрачный контроль достигается простым мониторингом неубывания количества голосов.
Одновременно с отключением функции отзыва голоса было введено довольно большое время кэширования счетчика голосов. Да, счетчик теперь не может уменьшаться, но нет способа проверить, что он будет увеличиваться ровно настолько, сколько человек проголосовало. Например, если в течении интервала кэширования независимо друг от друга проголосует 10 человек, а счетчик увеличится на 1, то каждый будет думать, что именно его голос учтен, хотя это не так.
Единственный вариант проверить систему в этом случае — это собрать в одном месте достаточно большое количество еще не голосовавших людей (больше чем среднее количество голосов за интервал кэширования) и проголосовать одновременно. Но даже если при этом счетчик увеличится на меньшее значение, чем количество проголосовавших, это все равно можно будет списать на особенности кэширования (мол, эти голоса были учтены только при следующих обновлениях счетчика).
Единственный вариант проверить систему в этом случае — это собрать в одном месте достаточно большое количество еще не голосовавших людей (больше чем среднее количество голосов за интервал кэширования) и проголосовать одновременно. Но даже если при этом счетчик увеличится на меньшее значение, чем количество проголосовавших, это все равно можно будет списать на особенности кэширования (мол, эти голоса были учтены только при следующих обновлениях счетчика).
Даже при отключении процедуры отзыва остаётся ещё масса способов подтасовать исход голосования.
Не обязательно же списывать голоса — можно устраивать вбросы. Резко увеличилось за секунду на 1000 количество голосов «против» инициативы.
Поэтому контроль — это всегда комплексная вещь, а не только «контролировать только один параметр».
Не обязательно же списывать голоса — можно устраивать вбросы. Резко увеличилось за секунду на 1000 количество голосов «против» инициативы.
Поэтому контроль — это всегда комплексная вещь, а не только «контролировать только один параметр».
Насколкьо я знаю, голоса «против» формально ничего не дают. Инициатива должна быть рассмотрена экспертной группой при наборе 100 000 голосов «за». Всё.
Хорошее замечание, спасибо. Я смутно припоминаю, что вроде действительно (на текущий момент) всё так и есть: голоса против не учитываются. Значит, подобным образом не получится злоумышленничать.
Какие ещё остаются альтернативы для злонамеренных манипуляций? Смотрим на число голосов «за», проверяем, что их не убывает. Всё?
Или что-то можно сделать такое?
Я вижу только ещё одну альтернативу: не учитывать голоса «за», хитрым образом закрывая подобный факт («число на счётчике кэшируется» или ещё что), об этом писали в комментариях к этой/прошлой статье.
Вроде точно всё?
Какие ещё остаются альтернативы для злонамеренных манипуляций? Смотрим на число голосов «за», проверяем, что их не убывает. Всё?
Или что-то можно сделать такое?
Я вижу только ещё одну альтернативу: не учитывать голоса «за», хитрым образом закрывая подобный факт («число на счётчике кэшируется» или ещё что), об этом писали в комментариях к этой/прошлой статье.
Вроде точно всё?
Для начала, РОИ генерирует 2048 битный RSA ключ-пару (SK, PK), где SK-секретный ключ и PK-публичный ключ.
О, опять этот глюк, когда путают понятия модуль/экспонента RSA и открытый/закрытый ключ.
Открытость или закрытость ключа — это не свойство RSA, это свойство сценария, в котором RSA применяется. Если RSA использовано в шифровании, открывают модуль, а если в ЭЦП — открывают экспоненту.
Кстати, почему RSA-то, в конце концов? Может, уже ECDSA задействуем?
Хмм… ну, можно взять EC 226 если с тем же уровнем секьюрити, или 256. Ну я так понял вы на размер кода (V, S) обратили внимание? Хотя, если поменять местами использование PK и SK то подпись в RSA будет работать в разы быстрее чем ECDSA (а верификация медленно), что важно для сервера. Как думаете?
RSA 2048 Encryption/Verification 0.16ms <<< наша цель по скорости
RSA 2048 Decryption/Signature- 6.08ms
ECDSA over GF(p) 256 Signature 2.88ms
ECDSA over GF(p) 256 Signature with precomputation 2.14ms
ECDSA over GF(p) 256 Verification 8.53ms
ECDSA over GF(p) 256 Verification with precomputation 3.58ms
Отсюда: www.cryptopp.com/benchmarks.html
RSA 2048 Encryption/Verification 0.16ms <<< наша цель по скорости
RSA 2048 Decryption/Signature- 6.08ms
ECDSA over GF(p) 256 Signature 2.88ms
ECDSA over GF(p) 256 Signature with precomputation 2.14ms
ECDSA over GF(p) 256 Verification 8.53ms
ECDSA over GF(p) 256 Verification with precomputation 3.58ms
Отсюда: www.cryptopp.com/benchmarks.html
Я думаю, что вам, как разработчику предложения, стоило бы не ограничиваться одним алгоритмом, а предложить по каждому пункту альтернативы, указав плюсы и минусы каждой. Про ГОСТ вам ниже тоже правильно написали.
Ну я понял, надо было просто в абстрактном виде подать. Назвать ассиметричный алгоритм X и алгоритм хеширования Y и все было бы верно. А там уже выбирай любой под них :)… я и правда, не подумал, что придется еще и список алгоритмов перечислять, плюсы-минусы, сравнивать их.
Так ваш подход тогда, простите, не очень-то отличается от РОИшного. Те тоже выбрали первый попавшийся вариант реализации, не рассмотрев плюсы и минусы альтернативных решений. Теперь неплохо бы переделать. А вам неплохо бы доказать, что за вами-то через 2 года переделывать не придётся.
Да мне по сути все равно что они там выберут в качестве X Y, главное чтобы по уровню безопасности подходило.
Я ради вас даже топик подправил, в конце собрал все претензии вместе в секции UPD. И потом, я вообще не в курсе кто и как это предложит в РОИ, и пойдет ли все это дальше куда то. Сам я активно этим заниматься точно не буду, на уровне идеи остановлюсь пожалуй. Денег мне за это не платят, семью не накормишь этим.
Я ради вас даже топик подправил, в конце собрал все претензии вместе в секции UPD. И потом, я вообще не в курсе кто и как это предложит в РОИ, и пойдет ли все это дальше куда то. Сам я активно этим заниматься точно не буду, на уровне идеи остановлюсь пожалуй. Денег мне за это не платят, семью не накормишь этим.
А почему, кстати, ГОСТ? Они там на РОИ ГОСТ применяют? Если так, то через что?.. Могу предположить OpenSSL Engine ГОСТовский какой нибудь (ну если это скрипты). Не писали же они SSL/TLS библиотеку всю с нуля.
В вектор V логично включить подпись предыдущего голоса.
Каждый следующий голосующий фиксирует все предыдущие голоса.
Каждый следующий голосующий фиксирует все предыдущие голоса.
А если одна запись «выпадет» или потеряется где то? Например, сам Масух проголосует а потом выдернет из БД? Вся последующая цепочка событий будет разорвана.
Еще совсем чуть-чуть допилить, и получится блокчейн.
Теоретически блокчейн добавить просто — SHA256(от предыдущего sign), это 32 байта к 49 — не проблема. Практически немного сложнее из за возможной рассинхронизации. Только не могу понять что это дает, против какой возможной атаки, какой сценарий тут?
Насчет блокчейна изначально была шутка: поскольку у нас система централизована, это не очень поможет — сервер РОИ по-прежнему имеет возможность незаметно вставлять несуществующие СНИЛСы (правда, каждый не более одного раза).
Но потом я заметил, что некоторая польза от цепочки всё же есть. Благодаря монотонности публикуемой информации, становится невозможно подбрасывать фальшивые голоса (с несуществующими СНИЛСами) задним числом, можно лишь по ходу дела. На первый взгляд от этого пользы мало, но тем не менее жизнь фальсификаторов осложняется — замести следы и уйти от ответственности намного труднее.
(Насчет технической реализации: не вижу проблем с синхронизацией, ведь сервер РОИ один, и может выстраивать полученные заявки в любой последовательности. То есть у него копится пул необработанных заявок, и он из пула их последовательно выбирает в произвольном порядке, встраивает в цепочку и отправляет уведомление. Это никак не параллелится, поэтому, если будут проблемы с производительностью, можно тянуть несколько цепочек одновременно, изредка провязывая их друг с другом. Тогда заявка будет считаться полностью валидной, если на нее есть ссылки из всех цепочек.)
Но потом я заметил, что некоторая польза от цепочки всё же есть. Благодаря монотонности публикуемой информации, становится невозможно подбрасывать фальшивые голоса (с несуществующими СНИЛСами) задним числом, можно лишь по ходу дела. На первый взгляд от этого пользы мало, но тем не менее жизнь фальсификаторов осложняется — замести следы и уйти от ответственности намного труднее.
(Насчет технической реализации: не вижу проблем с синхронизацией, ведь сервер РОИ один, и может выстраивать полученные заявки в любой последовательности. То есть у него копится пул необработанных заявок, и он из пула их последовательно выбирает в произвольном порядке, встраивает в цепочку и отправляет уведомление. Это никак не параллелится, поэтому, если будут проблемы с производительностью, можно тянуть несколько цепочек одновременно, изредка провязывая их друг с другом. Тогда заявка будет считаться полностью валидной, если на нее есть ссылки из всех цепочек.)
«подбрасывать фальшивые голоса (с несуществующими СНИЛСами) задним числом»
Ну, я с Вами отчасти согласен, но сильно такой необходимости подбрасывать назад я не вижу. Ну, во-первых сам счетчик будет гулять, если вы бросите назад на неделю (и это будет заметно), а если подбрасывать назад в пределах времени кэширования, то, опять же, нет нужны бросать назад на 5 минут, когда можно просто добавить в конец чейна. А вот объяснить Массуху такой чейн и как его реализовать — гораздо сложнее. Для таких людей на стол надо ложить самые простые схемы, чтобы уж совсем просто было понять.
Ну, я с Вами отчасти согласен, но сильно такой необходимости подбрасывать назад я не вижу. Ну, во-первых сам счетчик будет гулять, если вы бросите назад на неделю (и это будет заметно), а если подбрасывать назад в пределах времени кэширования, то, опять же, нет нужны бросать назад на 5 минут, когда можно просто добавить в конец чейна. А вот объяснить Массуху такой чейн и как его реализовать — гораздо сложнее. Для таких людей на стол надо ложить самые простые схемы, чтобы уж совсем просто было понять.
Я придумал, зачем фальсификаторам может понадобиться подбрасывать задним числом. Дело в том, что большинство инициатив безобидны или не вызывают ажиотажа у народа, поэтому вмешиваться, как правило, не нужно. Требуется лишь выявить опасные и популярные инициативы, и нужно время, чтобы осознать опасность и выявить тренд. Тогда и нужно принимать решение о вбросе, но если сделать его в конце голосования, то будет сильно заметно и подозрительно, поэтому лучше аккуратно размазать его во времени.
Второй момент заключается в следующем: допустим сделали вброс неаккуратно, так что народ заметил и возмутился; здесь лучше откатить назад, то есть извлечь фальшивые голоса из базы и заявить, что это хулиганы фальсифицировали фальсификацию, а сейчас, видите, какой на сайте правильный и по-гауссовски красивый результат.
Второй момент заключается в следующем: допустим сделали вброс неаккуратно, так что народ заметил и возмутился; здесь лучше откатить назад, то есть извлечь фальшивые голоса из базы и заявить, что это хулиганы фальсифицировали фальсификацию, а сейчас, видите, какой на сайте правильный и по-гауссовски красивый результат.
Пример можете привести? Выберите сценарий:
— Это инициатива: (а) моя, в которой я заинтересован, или (б) от РЖД, которую проталкивают кто то из РОИ?
— Вбросы назад будут какие — голоса ЗА или ПРОТИВ?
— Это инициатива: (а) моя, в которой я заинтересован, или (б) от РЖД, которую проталкивают кто то из РОИ?
— Вбросы назад будут какие — голоса ЗА или ПРОТИВ?
Пример достаточно прост — любая инициатива, которая противоречит политике партии власти и при этом окажется достаточно популярной. Тогда появляется интерес надавить на РОИ с целью вбросить голосов ПРОТИВ. Насчет того, что кто-то будет нечестным образом лоббировать свою инициативу, я как-то сразу не подумал, хотя такое тоже может быть. В любом случае, ситуация, когда власть хочет играть против воли народа, бывает достаточно часто, это нормально и естественно. Речь здесь идет о том, что если решаешься на фальсификацию, то выгоднее подбросить равномерно, а не кучей в конце. Цепочка лечит ровно этот случай.
UFO just landed and posted this here
Это всё верно, но есть некоторая сложность с поддержанием безденежных блокчейнов — получается, что никто из участником явным образом не заинтересован в поддержке системы по хранению данных и проверке корректности новых узлов. (Идея довольно очевидна, хотя я не сам придумал, а видел, кажется, в статьях у Виталика Бутерина (Ethereum), если нужно, поищу ссылку).
Отсюда вывод, что для системы голосования или чего-нибудь еще на основе блокчейна, требуется привязываться к существующей денежной системе (Bitcoin) или создавать новую (Ethereum).
В качестве альтернативы можно поставить задачу реализовать систему так, чтобы ее поддерживал кто-то централизовано, но при этом не требовал бы к себе доверия, то есть не мог бы добавлять невалидных узлов, и чтобы целостность блокчейна легко проверялась кем угодно. Я не знаю, возможна ли в принципе такая реализация.
Отсюда вывод, что для системы голосования или чего-нибудь еще на основе блокчейна, требуется привязываться к существующей денежной системе (Bitcoin) или создавать новую (Ethereum).
В качестве альтернативы можно поставить задачу реализовать систему так, чтобы ее поддерживал кто-то централизовано, но при этом не требовал бы к себе доверия, то есть не мог бы добавлять невалидных узлов, и чтобы целостность блокчейна легко проверялась кем угодно. Я не знаю, возможна ли в принципе такая реализация.
Отвечу сразу всем выше:
1. gbg. Это не умаляет сути понятий «секретный ключ» и «открытый ключ», а перегружать читателя тонкостями криптографии и определений думаю ни к чему. Важна суть.
2. ruikarikun. Да, я знаю что закрыли возможность отозвать голос. На сегодня достаточно 1 бита для типа голоса — да/нет. Ну а если завтра снова вернут возможность отзыва, то надо предусмотреть и такой вариант.
3. homm. Да, я позже тоже увидел похожие предложения. Но даже если кто то сказал что надо использовать ЭЦП (и верно сказал), то остается вопрос КАК именно. А поскольку у меня степень в области криптографии (извините за нескромность), то я предложил свое детальное решение — как должен выглядеть проверочный вектор, и что в него должно быть включено. Мог конечно где то ошибиться, но пока я ошибки не вижу, нужен взгляд со стороны.
1. gbg. Это не умаляет сути понятий «секретный ключ» и «открытый ключ», а перегружать читателя тонкостями криптографии и определений думаю ни к чему. Важна суть.
2. ruikarikun. Да, я знаю что закрыли возможность отозвать голос. На сегодня достаточно 1 бита для типа голоса — да/нет. Ну а если завтра снова вернут возможность отзыва, то надо предусмотреть и такой вариант.
3. homm. Да, я позже тоже увидел похожие предложения. Но даже если кто то сказал что надо использовать ЭЦП (и верно сказал), то остается вопрос КАК именно. А поскольку у меня степень в области криптографии (извините за нескромность), то я предложил свое детальное решение — как должен выглядеть проверочный вектор, и что в него должно быть включено. Мог конечно где то ошибиться, но пока я ошибки не вижу, нужен взгляд со стороны.
Я уточню еще раз, чтобы подчеркнуть масштаб трагедии:
В терминах RSA говорят о том, что модуль (то, чем шифруют), — это открытый ключ, а экспонента (то, чем расшифровывают) — это закрытый ключ. То есть по умолчанию считают, что RSA применяется по сценарию шифрования — любой может, зная мой открытый ключ (модуль) прислать мне текст, который расшифрую только я.
У вас же сценарий в точности обратный, у вас закрывают модуль (чтобы применять RSA мог только владелец подписи), а открывают — экспоненту (чтобы любой желающий мог RSA обратить и убедиться, что изготовитель верный). RSA применен в сценарии ЭЦП.
То есть относительно терминов типичного изложения RSA произошло переворачивание с ног на голову, которое может неискушенного читателя поставить в тупик с вопросом «Так каким же черт подери ключом шифруют? Толи открытым, толи закрытым?!!» (я ссылку на тостер дал выше). Так как криптография — дело тонкое, наплевательство здесь недопустимо, важна ясность.
В терминах RSA говорят о том, что модуль (то, чем шифруют), — это открытый ключ, а экспонента (то, чем расшифровывают) — это закрытый ключ. То есть по умолчанию считают, что RSA применяется по сценарию шифрования — любой может, зная мой открытый ключ (модуль) прислать мне текст, который расшифрую только я.
У вас же сценарий в точности обратный, у вас закрывают модуль (чтобы применять RSA мог только владелец подписи), а открывают — экспоненту (чтобы любой желающий мог RSA обратить и убедиться, что изготовитель верный). RSA применен в сценарии ЭЦП.
То есть относительно терминов типичного изложения RSA произошло переворачивание с ног на голову, которое может неискушенного читателя поставить в тупик с вопросом «Так каким же черт подери ключом шифруют? Толи открытым, толи закрытым?!!» (я ссылку на тостер дал выше). Так как криптография — дело тонкое, наплевательство здесь недопустимо, важна ясность.
«Так каким же черт подери ключом шифруют?» — В посте предельно четко указано каким ключем зашифровываем, а каким расшифровываем. А разошлись мы с Вами по части формулировок. Ценность и суть поста в другом — структура пары (V,S), то есть какая информация там должно быть, чтобы предотвратить возможные атаки. Если вы так категоричны, могу подправить формулировки заменив RSA на ЭЦП, и Encrypt/Decrypt на Sign/Verify. Так будет лучше?
А теперь представьте себе, что этот пост в сознании читателя напарывается хотя бы на статью из Википедии, где говорят, что в RSA шифруют открытым ключом, а обратно расшифровывают — закрытым. Читатель будет немножко в непонятках.
Разумеется, если вы подробно укажите, что RSA применяется по сценарию ЭЦП, да еще со ссылками на хорошие статьи с разъяснениями, откуда что берется, вы сделаете доброе дело!
Разумеется, если вы подробно укажите, что RSA применяется по сценарию ЭЦП, да еще со ссылками на хорошие статьи с разъяснениями, откуда что берется, вы сделаете доброе дело!
Открытость/закрытость ключа не зависит от сценария использования. Одна и та же пара ключей используется и для (1) шифрования/дешифрования, и для (2) подписи/верификации. Разница в том, что в первом сценарии вначале используется открытый ключ, потом секретный, а во втором — наоборот.
Это как это она не зависит, если в сценарии криптографии из пары раскрывают модуль, а в сценарии подписи из той же пары нужно раскрыть экспоненту?
То есть если человек желает подписывать и шифровать сообщения, ему надо две пары ключей. Если у него будет одна пара, он будет вынужден опубликовать из нее и модуль и экспоненту.
То есть если человек желает подписывать и шифровать сообщения, ему надо две пары ключей. Если у него будет одна пара, он будет вынужден опубликовать из нее и модуль и экспоненту.
Я исправил пост, и надеюсь на этот раз все окей. Извините, просто я не по-российским учебникам учился, и для меня ЭЦП — это немного странная аббревиатура. У нас тут RSA обозначает алгоритм, а ключи деляться на «RSA encryption key» и «RSA signing key» по типу применения. Поэтому такая чехарда с формулировками получилась. Надеюсь на понимание.
Да, вот теперь все стало на свои места. Непонятный момент «шифрования» заменен на «подписывание», и теперь становится понятным, что:
Исчезла путаница в ролях ключей, спасибо!
- Открытым ключом шифруют в сценарии шифрования и верифицируют электронную цифровую подпись
- Закрытым ключом расшифровывают шифрованное и подписывают электронной цифровой подписью
Исчезла путаница в ролях ключей, спасибо!
Я сейчас сходил на вики и освежил свои воспоминания по теме (в частности, я помнил, что для PGP достаточно было одной пары ключей на все случаи жизни). Там описана схема и шифрования, и верификации, и обе они использую одну и ту же пару ключей. Модуль (произведение пары простых чисел) входит в оба ключа (секретный и публичный), кроме того, в публичный входит произвольная (?) экспонента, а в секретный — комплементарная ей экспонента.
Все это гарантирует наличие отданного голоса — но никак не гарантирует отсутствие «дополнительных» голосов.
О чем, собственно, уже написано в посте:
Минусы:
• Невозможно отследить сценарий, в котором РОИ может добавлять голоса ЗА или ПРОТИВ для несуществующих СНИЛС. Но этот сценарий возможен и сейчас.
Об этом сказано в «минусах». Думаю, чтобы гарантировать отсутствие дополнительных голосов система должны быть на много сложнее, включая PKI независимый от РОИ, и ЭЦП для каждого пользователя. Это уже инфраструктура. Данное решение — то что можно сделать просто и прямо сейчас без дополнительных затрат.
Чтобы проверять отсутствие «дополнительных» голосов, нужно решить проблему «мёртвых душ».
Решение этого вопроса мне видится в открытой части баз данных государственных учреждений. Чтобы было видно, живёт ли владелец данного ID (СНИЛС или что-то другое). Без приватной информации, но записи типа «в таком-то роддоме родился такой-то» должны присутствовать. В такой ситуации нужно быть очень виртуозным, чтобы поддерживать виртуалов от самого рождения и нигде за это время не проколоться.
Решение этого вопроса мне видится в открытой части баз данных государственных учреждений. Чтобы было видно, живёт ли владелец данного ID (СНИЛС или что-то другое). Без приватной информации, но записи типа «в таком-то роддоме родился такой-то» должны присутствовать. В такой ситуации нужно быть очень виртуозным, чтобы поддерживать виртуалов от самого рождения и нигде за это время не проколоться.
UFO just landed and posted this here
Я им ничего не предлагаю и не собираюсь этого делать ни по емайлу, ни за 3000км. Надеюсь что это сделают другие если это кого то будет волновать больше чем меня… И обойдутся, пусть используют шифры на которых 2/3 мира работает. ГОСТ для меня вообще незнакомый зверь. На самом деле ответ на ваш вопрос я вынес в статью — там в конце есть прям список UPD.
Лучше предложите чем можно преодолеть упертость РОИ — это более сложная задача.
Лучше предложите чем можно преодолеть упертость РОИ — это более сложная задача.
Не совсем понимаю зачем такая сложность с критографией.
При голосовании РОИ может просто выдавать пользователю достаточно длинную для уникальности случайную строку.
Пользователь может записать себе куда-нибудь эту строку. Для удобства список всех строк полученных пользователем при голосовании за разные инициативы может быть в личном кибнете РОИ.
По каждой инициативе на РОИ публикуется список всех строк, разделенный на две части — «за» и «против».
Каждый пользователь может проверить, что его код есть в списке и его голос учтен. Более того он может опубликовать строку в другом месте — чтоб каждый мог проверить что он голосовал.
Любое третье лицо может просто посчитать количество строк — голосов «за» и «против».
При голосовании РОИ может просто выдавать пользователю достаточно длинную для уникальности случайную строку.
Пользователь может записать себе куда-нибудь эту строку. Для удобства список всех строк полученных пользователем при голосовании за разные инициативы может быть в личном кибнете РОИ.
По каждой инициативе на РОИ публикуется список всех строк, разделенный на две части — «за» и «против».
Каждый пользователь может проверить, что его код есть в списке и его голос учтен. Более того он может опубликовать строку в другом месте — чтоб каждый мог проверить что он голосовал.
Любое третье лицо может просто посчитать количество строк — голосов «за» и «против».
Допустим я не голосовал, а просто сгенерировал себе такую строку. А потом предоставил ее общественности и заявил «РОИ украла у меня голос, вот моя строка!» — как РОИ будет оправдываться? И как я докажу общественности что я действительно получил эту строку от РОИ? Приводить принтскрин что ли?
Да, согласен.
Можно продолжить список. РОИ просто одинаковые «случайные» последовательсти будет генерировать для, скажем, двоих. Оба видят себя в списке, а голос учтен один. Оба будут думать что все хорошо. Один голос зачтут, а второй украден.
Тут важно, чтобы со страницы инициативы можно было всегда скачать список этих последовательностей (с таймстампами и отсортированный по таймстампам) и каждый мог проверить, что:
- в списке столько же кодов, сколько и голосов
- они все уникальны
- там есть его код (если он голосовал)
- за время N между скачиваниями новые коды добавлялись только в конец списка
Все верно. Про кэширование не забудьте, между обновлениями данных может быть 5 минут, за которые у РОИ развязаны руки.
Тут уже обсуждали, как организовать честное электронное голосование взамен бумажному. Я не разбираюсь в теме, но вроде большинство сошлись во мнении, что это будет работать, и проблема только организационная. Как раз тут этой проблемы нет (у нас чисто электронное голосование).
Соглашусь с Вами что это возможно, и проблема организационная. Но у нас тут другой случай.
То о чем Вы говорите — по хорошему нужна полностью другая архитектура, но РОИ этого делать не будут. Они могут сделать лишь незначительные изменения в своей системе, и то возможно, если хорошо попросить. Приведенная схема предлагает минимум затрат для РОИ в конкретном случае, чтобы хорошие инициативы не теряли (не исчезали) живые голоса.
То о чем Вы говорите — по хорошему нужна полностью другая архитектура, но РОИ этого делать не будут. Они могут сделать лишь незначительные изменения в своей системе, и то возможно, если хорошо попросить. Приведенная схема предлагает минимум затрат для РОИ в конкретном случае, чтобы хорошие инициативы не теряли (не исчезали) живые голоса.
Вот по чеснаку мне эта анонимность на РОИ во многих случаях нафиг не уперлась. Я всё таки надеюсь что меня не будут политически прессовать за то что я поддержал ограничение стоимости авто для чиновников или против цензуры в интернете.
А если это не так то нафига так жить.
А если это не так то нафига так жить.
Я согласен и тоже могу в принципе публично объявить что да, я голосовал за такую то инициативу.
Проблема появляется тогда, где вам Моссух говорит что то о «конфиденциальности личных данных».
И тут нужны железобетонные аргуметы.
Проблема появляется тогда, где вам Моссух говорит что то о «конфиденциальности личных данных».
И тут нужны железобетонные аргуметы.
Мне кажется, в этой схеме не хватает доказательства того, что голосовали реальные люди.
Все обсуждение ушло в математику крипто-алгоритмы и прочее. Конечто это понятнее и интереснее, но почему-то никто не упомянул совершенно простую и очевидную вещь.
Какой смысл добавлять дополнительные гарантии того, что карты не крапленые, если выигрыш казино определяется не крапленостью карт, а правилами игры, которые определяет казино.
До тех пор, пока руководству не интересны наши инициативы, какой смысл обсуждать улучшение реализации этих инициатив.
Какой смысл добавлять дополнительные гарантии того, что карты не крапленые, если выигрыш казино определяется не крапленостью карт, а правилами игры, которые определяет казино.
До тех пор, пока руководству не интересны наши инициативы, какой смысл обсуждать улучшение реализации этих инициатив.
Меня честно говоря смущает другой момент: почему голосование на РОИ тайное? Сама инфраструктура ЭЦП подразумевает идентификацию с целью неоткрекаемости подписанных сведений. Можно сделать список подписей открытым хотя бы для какого-нибудь общественного наблюдательного совета и пусть общественники уже сами ищут недостоверные или скомпрометированные ЭЦП.
На Ваше предложение сделать список подписей открытым Массух скажет (точнее уже так ответил на подобное предложение), что это будет нарушать «конфиденциальность личных данных», поэтому отказ. Никаких проверочных общественных организаций не будет — угроза утечки личных данных.
«Конфиденциальность личных данных» нарушает личная электронная подпись, созданная с целью идентификации пользователя! Да что не так с этими людьми! Голос на РОИ отправляется путем подписания ЭЦП петиции, если кого-либо интересовала конфиденциальность, то для подписания генерировали бы анонимную (желательно разовую) подпись на основание уже созданного закрытого ключа.
1. Голосование тайное, а не открытое. Есть такое понятие как «тайна голосования» 2. Личная ЭЦП не создана для идентификации пользователя, а создана для верификации связи между каким либо событием (или данными) и пользователем. 3. Почему вы считаете что голос на РОИ подписывается с помощью ЭЦП пользователя? Откуда у Вас такая информация? И где, в таком случае, можно посмотреть открытые ключи всех людей на РОИ? Буду признателен.
Тайное оно чтобы не было никаких отрицательных последствий для проголосовавшего/не проголосовавшего. Понятно, что «в верхах»-то список всегда смогут получить, но «на местах» его практически наверняка не смогут увидеть и при этом сохранить в тайне, а если он выплывет — это будет гарантированный скандал, т.к. подлинность такого списка верифицируется на раз-два.
Все проблемы от анонимности.
Нужно публиковать список проголосовавших и все.
Если нет, то SHA(время голосования+ИД инициативы + СНИЛС).
Нужно публиковать список проголосовавших и все.
Если нет, то SHA(время голосования+ИД инициативы + СНИЛС).
А как потом проверить, что Константинопольский Иван Табуретович действительно существует?
Так… я, кажется, нашел дыру в системе. Но в целом знаю как ее прикрыть. Куда писать — тут или сразу в статью править?
Это-то как раз элементарно.
БД ФИО и СНИЛСов если не в открытом доступе, то довольно широко распространены.
БД ФИО и СНИЛСов если не в открытом доступе, то довольно широко распространены.
Друзья, я нашел дыру в системе. В статью добавил изменения для решения проблемы. Также добавил подкатом сценарий атаки и мотивацию.
Зачем совать UserSecret в H и усложнять себе жизнь? Достаточно было добавить его в V, всё-равно он весь подписывается.
Чтобы защитить СНИЛС от третьих лиц
В первой версии СНИЛС и так был защищен ключом SK.
А в этой самим пользователем. Ведь и СНИЛС и номер инициативы ему известен. В отличие от первой версии юзер может проверить правильность H.
Sign up to leave a comment.
Повышение доверия к РОИ при сохранении секретности персональных данных