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

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

Вариант 1. Простое взаимное подписание. Допуск по количеству подписей.

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

Минус этого варианта в том, что очень легко создать сеть виртуалов, которые подпишут ключи друг друга и этим выполнят условие по допуску.

Вариант 2. Иерархическое подписание ключей от ключа системы.

Вариант, который мы сейчас пытаемся исследовать с Юрием.

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

Если-же пользователь с нормально подписанным ключем захочет создать сеть виртуалов и подписать их этим ключем, мы используем другой механизм - распространение уровня доверия по сети подписывания.

Например, если главный ключ имеет уровень 1 и им подписано 4 других ключа. Тогда каждый ключ будет иметь уровень доверия 0.25 (хотя, лучше ключи подписанные ключем системы считать доверенными и имеющими уровень доверия 1). И т.д. по цепочке подписания.

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

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

Трудности возникают с созданием удаленных сетей доверия. Их возможно будет создавать только если хотя-бы один пользователь из этой сети получит подпись ключем системы. Такое подписание, думаю, должно быть только очным.

В общем, идея с распространением доверия по цепочке достаточно интересная, но не совсем понятно на каких критериях делать вывод о допуске или недопуске ключа к голосованию.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

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

_________________
89DC B598 306B 26C8 B9AA 5C0C CFB6 7184 B2B2 FF17

При первом варианте легко создается сеть виртуалов. Без возможности их как-то обнаружить.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Но и во втором случае легко создать сеть виртуалов с коэффициентов даже больше 1. При малом количество участников работают оба варианта. При большом ни один не работает без проверок по скайпу или очно. Но второй вариант сложней.

_________________
89DC B598 306B 26C8 B9AA 5C0C CFB6 7184 B2B2 FF17

Во втором случае вообще невозможен вариант коэффициента больше 1.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

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

_________________
89DC B598 306B 26C8 B9AA 5C0C CFB6 7184 B2B2 FF17

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Только проверки по скайпу и в реале заинтересованными в результате голосования сторонами. Это основное, остальное поможет слабо.

_________________
89DC B598 306B 26C8 B9AA 5C0C CFB6 7184 B2B2 FF17

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

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

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

На первое время достаточно проверки на определенное количество подписей, но это только до тех пор пока не станет достаточно большого числа пользователей.
Потом нам просто придется перейти на систему с главным ключом (иначе мы потеряем контроль).
Вариант системы проверки сети доверия БЕЗ главного ключа системы тоже возможен, но для этого нам понадобится достаточно большая группа ключей, которой мы уже будем доверять (ее как раз мы и получим используя алгоритм проверки по главному ключу).

ps Система "сети доверия" будет готова не скоро. Рекомендую подумать о "наколенных" вариантах, которые уже (или в самое ближайшее время) можно пустить в использование.