Небезопасно ли передавать вектор инициализации и соль вместе с зашифрованным текстом?

Я новичок в реализации шифрования и, по-видимому, все еще изучаю основы.

Мне нужна возможность симметричного шифрования в моей исходной кодовой базе. В эту систему входят три компонента:

  • Сервер, на котором хранятся некоторые пользовательские данные, и информация о том, зашифрована ли она, и как
  • Клиент С#, который позволяет пользователю шифровать свои данные простым паролем при отправке на сервер и расшифровывать с тем же паролем при получении
  • Клиент JavaScript, который делает то же самое и поэтому должен быть совместим с методом шифрования клиента С#

Посмотрев на различные библиотеки JavaScript, я наткнулся на SJCL, у которого есть прекрасная демонстрационная страница здесь: http://bitwiseshiftleft.github.com/sjcl/demo/

Из этого видно, что то, что нужно знать клиенту (помимо используемого пароля) для расшифровки зашифрованного текста:

  • Вектор инициализации
  • Любая соль, используемая для пароля
  • Размер ключа
  • Сила аутентификации (я не совсем уверен, что это такое)

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

Любые советы приветствуются.

ОТВЕТЫ

Ответ 1

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

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

Симметричное шифрование редко бывает достаточно для обеспечения безопасности; Само по себе шифрование защищает от пассивных атак, когда атакующий наблюдает, но не мешает. Для защиты от активных атак вам также нужна какая-то аутентификация. SJCL использует режимы шифрования CCM или OCB2, которые сочетают шифрование и аутентификацию, так что это прекрасно. "Сила аутентификации" - это длина (в битах) поля, выделенного для аутентификации в зашифрованном тексте; сила "64 бит" означает, что злоумышленник, пытающийся изменить сообщение, имеет максимальную вероятность 2 -64 чтобы добиться успеха, не будучи обнаруженным механизмом аутентификации (и он не может знать, успешно, без попытки, т.е. с измененным сообщением, отправленным кому-то, кто знает ключ/пароль). Этого достаточно для большинства целей. Большая сила аутентификации подразумевает больший зашифрованный текст, примерно на ту же сумму.

Я не рассматривал реализацию, но из документации кажется, что авторы SJCL знают свою профессию и делали все правильно. Я рекомендую использовать его.

Помните обычные оговорки паролей и Javascript:

  • Javascript - это код, который выполняется на стороне клиента, но загружается с сервера. Это требует, чтобы загрузка была некорректно защищена; в противном случае злоумышленник может вставить некоторый собственный код, например простой патч, который также регистрирует копию пароля, введенного пользователем где-то. На практике это означает, что код SJCL должен обслуживаться через сеанс SSL/TLS (т.е. HTTPS).

  • Пользователи - это люди, а люди плохо выбирают пароли. Это ограничение человеческого мозга. Более того, компьютеры продолжают становиться все более и более мощными, в то время как человеческие мозги продолжают становиться более или менее неизменными. Это делает пароли все более слабыми по отношению к атакам со словарями, то есть исчерпывающий поиск по паролям (злоумышленник пытается угадать пароль пользователя, пытаясь "вероятные" пароли). Зашифрованный текст, созданный SJCL, может использоваться в атаке в автономном словаре: злоумышленник может "попробовать" пароли на своих компьютерах, не проверяя их против вашего сервера, и он ограничен только своими компьютерными возможностями. SJCL включает в себя некоторые функции, которые затрудняют атаки в офлайн-словаре:

    • SJCL использует соль, которая предотвращает разделение затрат (обычно называемое "предварительно вычисленными таблицами", в частности "таблицы радуги", которые являются особым видом предварительно вычисленных таблиц). По крайней мере, злоумышленнику придется заплатить полную цену поиска словаря за каждый атакованный пароль.
    • SJCL неоднократно использует соль, путем ее добавления с паролем снова и снова, чтобы создать ключ. Это то, что SJCL называет "фактором укрепления пароля". Это делает переход от пароля к ключу более дорогим для клиента, но также и для злоумышленника, что и является точкой. Преобразование ключей в 1000 раз больше означает, что пользователю придется подождать, может быть, полсекунды; но он также умножает на 1000 стоимость для злоумышленника.