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

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

то, что нужно IV или salt, должно использоваться только один раз с заданным ключом или паролем. Для некоторых алгоритмов (например, шифрования 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 стоимость для злоумышленника.