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

Я сравнил наши схемы. Не вижу между ними разницы. Возможно, только удобства.

Если есть Уникальный Одноразовый Идентификатор Пользователя, то таблицу результатов голосований из моей схемы можно разделить на две: первая - 1. Уникальный Серийный Номер Голосования + 2. Числовое Представление Варианта Ответа. + Уникальный Одноразовый Идентификатор Пользователя; вторая - 3. Секрет Пользователя в Голосовании, подписанный закрытым ключом пользвателя. Сам Секрет Пользователя в Голосовании в это поле не вносится.
4. Специальное Поле. + Уникальный Одноразовый Идентификатор Пользователя. Получается ваша схема.

Ну у вас и битва....по хорошему завидую...)))

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


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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

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

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

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

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

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

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

При введении Уникального Одноразового Идентификатора Пользователя удобство одинаковое.



Нет, в моей в Таблице Участвоваших в Голосовании только два поля: Логин и подписанный Уникальный Серийный Номер Голосования. В нее вполне можно внести все те данные, которые есть в вашей схеме в Списоке голосовавших. Сути это не изменит.

Моя Таблица Результатов Голосования содержит данные из вашего Списока голосов и ваших "этих зашифрованных, подписанных данных" (простите, вы не определили термина для этих данных).

Так что я невполне понимаю, о чем вы говорите.

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Согласен, риск низкий, но он есть.



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



Не вижу, в чем неудобство?



Это правда. Единственное, можно ли связать открытый ключ и зашифрованные им данные.

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

Неудобство в том что в вашем варианте пользователю придется пытаться расшифровать своим ключем кучу данных (представьте себе голосование в масштабах РФ). На самом деле процедуры шифрования и расшифровки - весьма ресурсоемки. Мы этого обычно не замечаем, т.к. шифруем небольшие объемы данных. А если еще использовать токены с контроллером который сам по себе достаточно слаб, то попытка расшифровки таких объемов становится просто нереальной.

Вторая проблема - кто или что будет определять что при расшифровке получился "осмысленный результат"? Сам пользователь будет просматривать миллионы результатов расшифровок в попытке найти "осмысленный"? Или мы будем создавать искусственный разум, который будет сам определять "осмысленность" текста?

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


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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68