- комментарий 0:
From: kmeaw
Date: 2020-11-17 09:04:21Z
> Голосование на blockchain
> Do you need a public blockchain? The answer is almost certainly no.
> A blockchain probably doesn’t solve the security problems you think it
> solves.
Если chain публичный, то будет очень легко задокументировать изменение
истории. Если я проголосовал, а после меня кто-то ещё, то будет
проблематично выкинуть или изменить мой голос так, чтобы те, кто
голосовали после меня, не заметили изменений, проверяя наличие своего
"коммита" в цепочке.
А какие схемы для голосований предлагает использовать Шнайер?
- комментарий 1:
From: Sergey Matveev
Date: 2020-11-17 09:12:50Z
*** kmeaw [2020-11-17 11:59]:
>Если я проголосовал, а после меня кто-то ещё, то будет
>проблематично выкинуть или изменить мой голос так
Сразу же вопрос про тайну голосования. Плюс, представим что ты просто
подписался своим публичным ключом, известным каждому. Если они в
какой-то публично доступной БД увидят твою валидную подпись, то факт что
ты проголосовал будет подтверждён. Тебе же на руки могут выдать подпись
о том что ты проголосовал, которая продемонстрирует что система учла
голос и факт его отсутствия тоже будет обнаружен. Связанность и учёт
порядка тут не нужны. Это не предложение работающей системы, а просто
пример того, что blockchain тут не к месту.
>А какие схемы для голосований предлагает использовать Шнайер?
Их много, какой-то одной лучшей нет. Я думаю проще поискать это в его
"прикладной криптографии", где вроде целая глава по этому есть. А так то
на эту тему тьма статей на eprint.iacr.org выходит.
- комментарий 2:
From: kmeaw
Date: 2020-11-17 10:23:47Z
> Сразу же вопрос про тайну голосования.
С этим есть отдельные сложности. Пока предположим, что эта задача
решается какой-то отдельной сущностью, или не решается вовсе.
Например, можно хранить список всех паспортов, владельцы которых
получили сертификат, который генерируется на месте - голосующий
генерирует пару (priv, pub), отдаёт pub, получает сертификат "владелец
пары с фиксированным pub имеет право на один голос", и попадает в список
паспортов, чтобы исключить повторный выпуск такого сертификата.
Если подвергнуть эту сущность аудиту и запретить ей хранить
сопоставления сертификат<->паспорт (и исключить все побочные каналы,
позволяющие такое сопоставление восстановить), то тайна голосования
вроде бы не нарушается.
> Связанность и учёт порядка тут не нужны.
Согласен, задача учёта голосов не требует этих свойств, но они
накладывают довольно сильные ограничения на злоумышленника.
Остальное я пока не понимаю.
Если в какой-то публичной БД была некоторая запись, а потом исчезла, а я
хочу доказать факт того, что она была, то мне может помочь либо подпись,
поставленная администраторами этой базы (тогда я сохраню её в тот
момент, пока запись ещё не исчезла), либо свидетельские показания
очевидцев.
В случае, когда все записи упорядоченны и подтверждают порядок
следования друг-друга, все вынужденным образом становятся этими
свидетелями. То есть даже если человека волнует только правильность
учёта лишь его голоса (а на мой ему наплевать), то факт неизменности его
коммита (если он произошёл после моего) автоматически гарантирует
неизменность моего. А в случае с просто базой данных много участников
должны быть заинтересованы регулярно делать снапшоты базы, причём они
должны содержать ещё и подпись администратора.
- комментарий 3:
From: Sergey Matveev
Date: 2020-11-17 10:49:12Z
*** kmeaw [2020-11-17 13:18]:
>С этим есть отдельные сложности. Пока предположим, что эта задача
>решается какой-то отдельной сущностью, или не решается вовсе.
Ну в принципе то решается. С ходу не помню как именно, разве что про про
слепые подписи. Вспоминать надо...
>Если подвергнуть эту сущность аудиту и запретить ей хранить
>сопоставления сертификат<->паспорт (и исключить все побочные каналы,
>позволяющие такое сопоставление восстановить), то тайна голосования
>вроде бы не нарушается.
Чего-чего, но этому доверять нельзя. С криптографической точки зрения. В
данном случае это снова доверие конкретным людям, организациям. Так то
из коробки взаимосвязь у нас есть между человеком и его сертификатом. С
таким же успехом можно доверять и просто тому, что знание
сертификат<->паспорт не будут использованы во вред.
>В случае, когда все записи упорядоченны и подтверждают порядок
>следования друг-друга, все вынужденным образом становятся этими
>свидетелями.
Я не понимаю что это даёт и чем отличается от просто наличия на руках
подписанного штампа что такой-то ключ "проголосовал". Какая разница
сколько свидетелей? Задача иметь возможно доказать что голос был, а в БД
его не видно -- вот, на руках у человека будет штамп подписанный.
Когда я голосую (отправляю свою подпись), то нет гарантий что в цепочке
моя подпись появится и её среплицируют наблюдатели -- её могут сразу же
исключить из цепочки например. Если же мы просто хотим среплицировать
факты/знания о голосах, то можно просто делать broadcast канал, но в
котором, опять же, нет никакого смысла что-то там связывать между собой.
Свидетели (те кто следят за репликацией) могут "сговориться" (в общем
случае) и "забыть" про какие-то голоса. А ЭЦП (обычную) -- нельзя
"отозвать".
>То есть даже если человека волнует только правильность
>учёта лишь его голоса (а на мой ему наплевать), то факт неизменности его
>коммита (если он произошёл после моего) автоматически гарантирует
>неизменность моего. А в случае с просто базой данных много участников
>должны быть заинтересованы регулярно делать снапшоты базы, причём они
>должны содержать ещё и подпись администратора.
Я это вижу просто как попытка какой-то оптимизации
размеров/производительности. Для задач голосования это всё небольшие
данные, людей не так много, поэтому зачем всё усложнять и оптимизировать
то что не требует этого?
Есть много вопросов, как минимум с тайной голосования связанных. Есть
множество предложений и решений по голосованию. Это очень сложная тема
(судя по книгам). Почему их не используют? Наверное потому что это не
нужно гос-вам и правительствам. Плюс это наверное просто тупо слишком
дорого и, опять же, овчинка выделки не стоит. Это ж у каждого какие-то
технические средства должны быть, которым ещё и доверять надо как-то.
Ведь есть же "Чаумовские" криптовалюты, которые ну всем хороши (да, есть
доверенная сторона в виде банка) для замены налички, даже анонимны,
но... это не нужно и не стоит того, ибо многие люди хотят темнить и
делать что-то нечестно, к сожалению. Но это уже политика.
- комментарий 4:
From: kmeaw
Date: 2020-11-17 11:27:06Z
> *** kmeaw [2020-11-17 13:18]:
> > или не решается вовсе.
Я к тому, что предлагаю выкинуть обеспечение тайности голоса за пределы
этого обсуждения, потому что там много сложностей, которые обсуждать
лучше отдельно.
> Задача иметь возможно доказать что голос был, а в БД его не видно --
> вот, на руках у человека будет штамп подписанный. Когда я голосую
> (отправляю свою подпись), то нет гарантий что в цепочке моя подпись
> появится и её среплицируют наблюдатели -- её могут сразу же исключить
> из цепочки например. Если же мы просто хотим среплицировать
> факты/знания о голосах, то можно просто делать broadcast канал, но в
> котором, опять же, нет никакого смысла что-то там связывать между
> собой. Свидетели (те кто следят за репликацией) могут "сговориться"
> (в общем случае) и "забыть" про какие-то голоса. А ЭЦП (обычную) --
> нельзя "отозвать".
Если в обмен на мой голос я просто буду получать сертификат "ваш голос
учтён, digest вашей посылки такой-то", то это не даст мне возможности
верифицировать БД. Единственное, что я смогу сделать, если посчитаю
выборы нечестными и требующими пересмотра, это собрать вместе людей,
которые тоже голосовали за того же кандидата, в количестве N, большим,
чем M, которое получено после подсчёта голосов.
Если же в обмен на голос я буду получать сертификат "ваш голос учтён,
сейчас база находится в состоянии Sn, а до этого находилась в состоянии
Sn-1", то мне достаточно будет найти другой сертификат, рассказывающий,
что база перешла из состояния Sn-1 в состояние Sn', отличное от Sn - это
и будет доказательством того, что база забыла мой голос. А как доказать
факт пропажи голоса при использовании только ЭЦП?
По сути это просто надстройка над broadcast каналом, позволяющая
договориться об актуальном состоянии, если кто-то из наблюдателей что-то
пропустил.
Сговариваться наблюдатели не будут в том случае, если любой желающий
сможет стать новым наблюдателем.
- комментарий 5:
From: Sergey Matveev
Date: 2020-11-17 11:45:43Z
*** kmeaw [2020-11-17 14:22]:
>Если в обмен на мой голос я просто буду получать сертификат "ваш голос
>учтён, digest вашей посылки такой-то", то это не даст мне возможности
>верифицировать БД.
Это и так не даёт: вы получаете хэш/слепок какой-то цепочки голосов. Как
понять такую же цепочку видят остальные? Как понять что другой человек
получил свою цепочку с вашей подписью/хэшом? Всё что происходит после
вашей подписи -- вам тоже роли не играет.
>А как доказать факт пропажи голоса при использовании только ЭЦП?
Вы в любом случае не знаете получаете ли вы корректную информацию из
"центра сбора голосов". В любом случае людям/наблюдателям надо собраться
и проверить свои цепочки, свою получаемую информацию. Это не требуется
делать быстро, в real-time. Это можно сделать ровно один раз, после
закрытия "выборов" и просто например тупо отсортированные подписи
прохэшировать и сравнить сходятся ли они. Цепочка тут просто является
оптимизацией подобного сравнения. Но она может наложить сложности на
"центр сбора", так как его состояние, грубо говоря, требует lock-а чтобы
наращивать цепочку.
>По сути это просто надстройка над broadcast каналом, позволяющая
>договориться об актуальном состоянии, если кто-то из наблюдателей что-то
>пропустил.
Да, я это и имел в виду под оптимизацией. Это точно такой же, тот же
самый broadcast, просто в котором не хаотично всё, а сразу линейно
выстраивается и можно сравнивать верхушки. Так как для голосования,
время совершенно не критично, да и объёмы небольшие, то... ну ok,почему
бы и нет, просто это оптимизация ради оптимизации, ибо проблем с
подсчётом/сравнения для задач голосования я не вижу (даже если взять
китайцев/индусов которых за миллиард в одной стране).
Безусловно я может и преувеличиваю геморрой для "центра сбора", но,
чисто мысли в слух, голоса он бы мог просто скидывать себе в общую кучу,
очередь обработки, просто в директорию валить скопом, а затем разгребать
как угодно, без какого-то глобального lock-а, нужного для выстраивания
цепочки. Хотя... учитывая объёмы (кол-во людей), это тоже смехотворно об
этом переживать. Но по моему это усложнение ради оптимизации,
потребности в которой нет.
>Сговариваться наблюдатели не будут в том случае, если любой желающий
>сможет стать новым наблюдателем.
Чего никогда не будет, чисто по человеческим причинам. И это уже доказал
Bitcoin и все публичные blockchain системы. Люди не объединяются, люди
не кооперируют -- в основной своей массе. Все предпочитают это
делегировать отдельной группе. Ведь люди даже не в состоянии в массе
своей использовать федеративные средства общения (ибо на 1-2 кнопочки
или настройки больше -- это уже считается сложным). Если считать что
будет написан софт, который по одному клику может автоматически
реплицировать данные с "центра сбора" и проверять их, то... доверие
перемещается в группу разработки этого софта, что равносильно просто
делегированию наблюдению этой отдельной группе.