Ответ 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 стоимость для злоумышленника.