Я новичок в криптографии. Мне для работы с клиентами понадобился протокол защиты и идентификации записей в базе данных. Покритикуйте, пожалуйста, мою задумку.
Постановка задачи:
Сервер БД - на платформе провайдера. Пользователи системы могут вносить данные, которые затем должны прочитать (сами непосредственно, либо через доверенных лиц). Данные конфиденциальные и шифруются на стороне клиента, т.к. эти данные не должны быть доступны ни администратору сервера БД, ни сисадмину провайдера.
Собственно клиент, а также администратор БД должны иметь возможность однозначно идентифицировать принадлежность записи ее создателю, например, на основе ЭЦП. Причем администраторы серверов и др. клиенты не должны иметь возможности подделать факт принадлежности записи лицу, создавшему/изменившему эту запись.
Прадлагаемая структура записи БД:
Открыто сохраняется Id записи, время ее создания/измененеия и код предприятия-владельца записи.
Конфиденцальные данные документа состоят из нескольких полей, шифруемых ключом клиента (предположим, симметричный алгоритм). К ним добавляется некоторое случайное поле, которое также шифруется тем же ключом. Перед шифрованием для результата конкатенации всех этих полей, разделённых некоторым символом-разделителем, вычисляется хэш-сумма, которая сохраняется в открытом виде. Для этой хэш-суммы (либо для ее конкатенации со временем создания/изменения, с кодом клиента и с Id записи) создается электронная подпись. Созданная ЭЦП сохраняется в соответствующем поле записи.
Случайное шифруемое поле введено для исключения атаки типа брют-форс на текст небольших документов с известной хэш-суммой.
На первый взгляд все хорошо - критичные данные зашифрованы, администратор БД может проверить аутентичность записей и целостность незашифрованной части всех записей в БД. Клиент может полностью восстановить документ и проверить его ЭЦП.
Однако, есть такое ощущение, что тут не все гладко - например, открытая хэш-сумма может давать дополнительное ограничение, которое в результате снизит стойкость (разрядность) применяемого алгоритма шифрования. Или случайное шифруемое поле каким-то образом может быть использовано для создания коллизий.
Подскажите, пожалуйста, насколько обоснованы мои подозрения?
Постановка задачи:
Сервер БД - на платформе провайдера. Пользователи системы могут вносить данные, которые затем должны прочитать (сами непосредственно, либо через доверенных лиц). Данные конфиденциальные и шифруются на стороне клиента, т.к. эти данные не должны быть доступны ни администратору сервера БД, ни сисадмину провайдера.
Собственно клиент, а также администратор БД должны иметь возможность однозначно идентифицировать принадлежность записи ее создателю, например, на основе ЭЦП. Причем администраторы серверов и др. клиенты не должны иметь возможности подделать факт принадлежности записи лицу, создавшему/изменившему эту запись.
Прадлагаемая структура записи БД:
Открыто сохраняется Id записи, время ее создания/измененеия и код предприятия-владельца записи.
Конфиденцальные данные документа состоят из нескольких полей, шифруемых ключом клиента (предположим, симметричный алгоритм). К ним добавляется некоторое случайное поле, которое также шифруется тем же ключом. Перед шифрованием для результата конкатенации всех этих полей, разделённых некоторым символом-разделителем, вычисляется хэш-сумма, которая сохраняется в открытом виде. Для этой хэш-суммы (либо для ее конкатенации со временем создания/изменения, с кодом клиента и с Id записи) создается электронная подпись. Созданная ЭЦП сохраняется в соответствующем поле записи.
Случайное шифруемое поле введено для исключения атаки типа брют-форс на текст небольших документов с известной хэш-суммой.
На первый взгляд все хорошо - критичные данные зашифрованы, администратор БД может проверить аутентичность записей и целостность незашифрованной части всех записей в БД. Клиент может полностью восстановить документ и проверить его ЭЦП.
Однако, есть такое ощущение, что тут не все гладко - например, открытая хэш-сумма может давать дополнительное ограничение, которое в результате снизит стойкость (разрядность) применяемого алгоритма шифрования. Или случайное шифруемое поле каким-то образом может быть использовано для создания коллизий.
Подскажите, пожалуйста, насколько обоснованы мои подозрения?