Проект "Свободные голосования"

Такие ситуации система отслеживает. Количество голосов не может стать больше чем количество зарегистрированных подписей в голосовании.

Кстати, в описании алгоритма я это сделал неправильно. Запросы там все-таки синхронные.

1. Регистрируется голосующий - на сервер отправляется запрос с подписью голосующего. Без его выбора. Возвращается ID данной записи.
2. Если предыдущий запрос прошел нормально - отправляется запрос с одноразовым идентификатором пользователя и его выбором.
3. Если второй запрос прошел неудачно, то вызывается процедура отката первого запроса.
4. Если второй запрос прошел удачно, то вызывается процедура его подтверждения.

Конечно, если будет обрыв между первым и вторым запросом, то в базе останется неподтвержденная подпись. Но такие подписи достаточно легко обнаружить.

Также возможно что обрыв произойдет, например, между отправкой голоса и подтверждением подписи. Тут мы будем иметь ситуацию с корректной БД, но с неподтвержденной подписью. В принципе, их тоже можно корректно обработать. Например, выдать пользователю на его персональной странице предупреждение что в базе есть такие его подписи и что-бы он решил что с ними делать - подтвердить или удалить.


На самом деле тема голосования, а особенно тайных, с использованием делегирования у нас еще в зачаточном состоянии. Пока видно кучу проблем с ними связанных, но не видно решений.


Описал выше.


Вполне определенное и детектируемой. Пригодное для логической обработки.


Думаю, в данном случае лучше удалять неподтвержденную подпись и дать возможность пользователю проголосовать еще раз. Не думаю что отдельная процедура "доголосования" это хорошая идея.


Удаления непарных подписей - легко. А непарных голосов быть не может - их система просто не допустит.


Надо просто дописать эту обработку. Сейчас ее еще нет, но сделать реально.

Кстати, обновите исходники и БД (БД выложу отдельно и скину ссылку). Для двухфазной процедуры описанной выше добавил там поле status в таблицу votes_voters_list. Функционально там все было для этого готово, но я почему-то не довел процедуру до логического завершения. Сегодня в процессе общения с вами доделал.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Нет, тут как раз запросы проходят не синхронно. Хотя сами запросы синхронные по типу, то есть до получения подтверждения, что запись о факту голосования помещена в базу, никакие другие действия не выполняются.

Собственно, получаем ситуацию с "доголосованием" или, по желанию, отменой голосования. В любом случае, как я понял, такая запись имеет статус незавершённого голосования и просто не будет учитываться при проверке валидности базы.

Тут лучшим, как мне кажется, является вариант "следуй за мной", потому что избавляет от лишних заморочек со структурой базы и вообще предельно упрощает систему - серверу остаётся только учесть, кому делегирован голос по этому голосованию и уведомить пользователя и его ПО о сделанном делегатом выборе. Пользователь уже может либо ничего не делать, чтобы ПО само проголосовало вслед за лидером, либо изменить выбор. Единственный, наверное, недостаток - нужно, чтобы к моменту завершения голосования это ПО было активно и могло последовать за лидером, если пользователь не решил проголосовать сам.

Чем проще, тем надёжнее, при прочих равных.

Хорошо. Кстати, предлагаю вывести справочники в отдельный файл(ы), чтобы не приходилось тянуть каждый раз по 30 метров. Кстати, тогда можно складывать в проект дамп только структуры базы и он будет обновляться автоматически.

Постгреса всё ещё не победил: базу сделал, а вот прицепиться к ней не получается. Так что пока всё только теоретически .

Я его смотрел. Андрей там всё правильно разобрал. А вот это

Вообще как-то странно: если я зашифровал данные, потом, поверх моего шифрования, их кто-то ещё зашифровал, то я не смогу расшифровать. Просто потому, что это невозможно. Или имелось ввиду заверение подписи подписью случайного пользователя системы? Но тогда надо уже смотреть окончательный вариант.

Вообще, представьте себе, что чьё-то ПО будет неактивно. Как отправлять тогда? В общем, чем проще, тем лучше, мне кажется. Просто потому что меньше мест для сбоев. Вот с двумя слабо связанными таблицами, данные в которые вносятся в разных транзакциях, уже возникает проблема сбоев в связи и появления "висячих" записей. А Вы предлагаете ещё один этап, причём, работающий по ненадёжным каналам клиентов. Да, канал клиент-сервер я считаю более надёжным, потому что там есть достаточно надёжный кусок, на котором сервер висит, а здесь на обоих конца не разбери поймёшь что.

Кстати, незабываем, что у пользователя, в общем случае, все входящие порты закрыты. Например, потому, что он может сидеть на серых адресах. В Москве такое как нефиг делать. Ну и маршрутизатор далеко не всегда подконтролен пользователю, так что не прокинешь порт.

Проблема в данном случае при тайных голосованиях в том, что если делать так, то голос делегата уже станет НЕ тайным. Что некорректно в принципе.

И на всякий случай напоминаю, что при просмотре результатов голосования НЕ должно быть никакой информации которая выдавала-бы сколько голосов у какого делегата имеется. В идеале, эта информация должна быть закрытой и для самого делегата, т.к. она будет ухудшать объективность голосования делегата и создаст почву для злоупортреблений.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Алгоритм Шамира. http://www.textreferat.com/referat-1143-2.html

Отправляйте активным.

Это не проблема. rfc5389
В худшем случае на первое время можно использовать "сервер" системы для связывания этих пользователей.

Интересно. Криптография для чайников . Буду читать.

Не самый лучший вариант, на самом деле. Мне сильно не нравится идея запуска сервера, смотрящего наружу, на клиентской машине. Разве что попытаться всё-таки гонять через сервер, отдавая данные в ответ на периодические запросы через AJAX.

Да решает проблему, кроме случаев самой тяжёлой паранойи корпоративных админов. Но остаётся вопрос: это у нас всё-таки сайт с маленьким агентом, который занимается только шифрованием, или полновесный клиент пиринговой сети?

Хорошо, проголосовал делегат, за ним система тянет голоса делегировавших. Причём, сразу, потому что потом информация о том, что вот этот делегат проголосовал так-то, будет потеряна. Значит, надо записывать всем последователям тот же выбор. НО. Проблема - у сервера нет ключей этих последователей, а значит он не может корректно подписать результат выбора. Подписывать всё ключом делегата? Это нарушит принцип "один человек - один голос". Причём, делегирование надо закладывать уже сейчас, чтобы не обнаружилось, что забыли подземный гараж, когда уже крышу кроют.

Надо срочно разбираться с постгресом, а то без копания в коде и базе сложно думать.

Я предлагал вариант делегирования голоса делегату через выписывание ему заранее подписанных пользователем всех вариантов решений. Т.е. пользователь не отказывается голосовать, но не знает какой вариант выбрать и доверяет этот вопрос решить делегату.

Минус тут в одном - такое делегирование возможно только для конкретного голосования. Невозможно будет сделать неограниченное делегирование, например, на какой-то срок.

Ну и все-равно остается проблема проверки - свой голос пользователь может проверить, но не может при этом проверить как голосовал делегат. Возможны махинации изнутри системы.

Вообще, в GPG есть такая штука как "подключи". С ними я еще не разобрался - возможно они могут помочь в этой проблеме.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Кстати, а не хотите рассмотреть возможность использования готовых решений по криптозащите? Ну например как в системе Телебанк от ВТБ?
Все уже есть, причем софт там используется сторонний:
http://www.signal-com.ru/ru/prod/documents/inter_pro/
А у разработчиков этого софта есть все необходимые лицензии. Для его использования, подозреваю, лицензия не требуется. Сертификаты как я понимаю там любые можно использовать.

Это клиентская часть. Для того что-бы использовать серверную часть и предоставлять услуги на ее основе, все-равно нужны лицензии ФСБ.

Кроме того, использование технологии НЕ opensource сразу закладывает в систему бомбу замедленного действия. Т.к. в любых системах шифрования которые лицензирует ФСБ есть бэк-доры.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68