Это небезопасно передавать вектор инициализации и соль вместе с зашифрованным текстом? - PullRequest
16 голосов
/ 03 октября 2010

Я новичок в реализации шифрования и, кажется, все еще изучаю основы.

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

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

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

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

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

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

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

1 Ответ

33 голосов
/ 03 октября 2010

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

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

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

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

Запомните обычные предостережения о паролях и Javascript:

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

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

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