Только что слышал подкаст, в котором утверждалось, что SSL не работает для ключей небольшого размера.
Они сказали, что вам следует использовать настолько надежный ключ, насколько вы можете себе позволить, не говоря уж о том, каких размеров ключей следует избегать.
Итак, вопрос в том, есть ли рекомендуемый минимальный размер ключа?
Большой размер модуля - это защита от попыток грубой силы восстановить ваш закрытый ключ злоумышленником, у которого есть только ваш открытый ключ. Больше битов - это больше вариаций, которые нужно проверить, но на практике даже «меньшие» размеры ключа довольно сложно попытаться атаковать.
Что касается конкретных размеров, то 512-битный ключ на данный момент считается довольно небезопасным, так как было продемонстрировано, что его можно взломать в течение нескольких месяцев при наличии достаточных вычислительных ресурсов. 1024-битные ключи все еще немного недосягаемы, но ожидайте, что они будут взломаны (кем-то с огромными вычислительными ресурсами) в течение следующих 5 лет. 2048-битные ключи, вероятно, недоступны до тех пор, пока квантовые компьютеры не станут работоспособными, и в этот момент все, что использует криптографию с открытым ключом, в значительной степени выпадает из окна.
Помимо прямой безопасности пары ключей, существуют и другие недостатки алгоритмов хеширования, используемых для подписи; На этом этапе MD5 полностью нарушен, и любой центр сертификации, который подпишет сертификат с использованием MD5, уязвим для атак с коллизией. Это было продемонстрировано пару лет назад группой, которая создала мошеннический центр сертификации, сопоставив его хэш MD5 с хешем легитимного сертификата, который они были подписаны одним из доверенных корневых провайдеров.
Да, и множество проблем в других аспектах, включая небезопасные реализации, такие как SSL v2, слабые места в спецификациях, такие как атака повторного согласования, и слабые шифры, которые по-прежнему включены на большинстве веб-серверов из-за устаревших клиентов. Все эти аспекты должны быть учтены при рассмотрении вопросов безопасности SSL.
Однако для размера ключа; нет причин не использовать большие. Затраты, связанные с использованием ключей большего размера, тривиальны (дополнительное время вычислений для проверки сертификата).
Только что слышал подкаст, в котором утверждалось, что SSL не работает для ключей небольшого размера.
Эмм, нет. SSL (что сегодня предположительно означает TLS 1.0 или новее) не сломан.
В Обмен ключами RSA известно, что есть недостатки при использовании с ключами меньшего размера (768 бит и ниже). Обычно это смягчается увеличением размера ключа.
Итак, вопрос в том, есть ли рекомендуемый минимальный размер ключа?
Да. Специальная публикация NIST 800-57 рекомендует 2048 бит с 2011 по 2030 год (таблица 4). это сообщение в блоге содержит краткий обзор.
Итак, если вам нужна официальная рекомендация, это 2048 бит. Но подумайте о том, что вы обеспечиваете и каков ваш профиль риска. Например, если вы просто обеспечиваете состояние входа пользователя (представьте себе пользователя, который вошел в социальную сеть, и ему нужно, чтобы его логин был защищен, но фактическая представленная информация является общедоступной), тогда 1024-битный или 1536-битный RSA key, вероятно, тоже хороший выбор. См. Эти обсуждения на Security.Stackexchange для получения некоторых квалифицированных мнений о размерах ключей и компромиссах использования ЦП - Вот и Вот.
Звучит как известная ошибка Debian SSL. Хотя ошибка была специфичной для Debian, насколько мне известно, все меньшие размеры ключей оказались бесполезными.
У меня сейчас нет ссылки, но в моей голове есть не менее 2048 бит для ключей, плавающих вокруг. Для дополнительной информации: многие инструменты ломаются, когда сертификаты имеют md5 в качестве алгоритма хеширования - это поразило меня некоторое время назад, и потребовалось время, чтобы понять, поскольку сами сертификаты и ключи были абсолютно в порядке.
Мне нравится подход Брюса Шнайера: «Криптография - это залог безопасности». Чем больше размер ключа, тем больше запас прочности (и тем больше падение производительности). 512-битный ключ, вероятно, хорошо, но, вероятно, ненадолго. Как упомянул Шейн Мэдден, существует достаточно доказательств того, что они могут быть сломаны согласованной атакой менее чем за несколько месяцев. Если для вас достаточный запас прочности, то вам не нужно сразу их заменять. Возможно, на очереди 1024-битные ключи.
Так что, если у вас уже есть приобретенные вами цифровые сертификаты, в которых используются ключи этих размеров, и вы НЕ защищаете важные корпоративные / ядерные секреты, вы, вероятно, хорошо на короткий срок, но в будущем вы захотите приобрести SSL-сертификаты с большим размером ключа. Есть ли у вас достаточно большой запас прочности? Стоит ли удар по производительности? Кто будет атаковать вашу криптосистему? Небольшой анализ угроз хорош для А) выяснения, нужно ли что-то делать СРАЗУ и Б) прикрытия задницы на случай, если случится что-то плохое.
Какого размера ключ следует использовать в криптосистеме RSA?
Что касается замедления, вызванного увеличением размера ключа (см. Вопрос 3.1.2), удвоение длины модуля в среднем увеличивает время, необходимое для операций с открытым ключом (шифрование и проверка подписи) в четыре раза, и увеличивает время, затрачиваемое на операции с закрытым ключом (расшифровка и подпись) в восемь раз.
Что касается того, как это снижение производительности будет выглядеть в реальном мире, оно действительно зависит от вашего приложения и реализации. Это может увеличить время в четыре раза, что дает дополнительные 4/10 секунды, или может составить четыре секунды. Здесь важно тестирование.
Похоже, на данный момент NIST (СП800-131А) считает, что размеры ключей RSA и DSA 2048 являются приемлемыми только после 2011–2014 годов, и они должны иметь не менее 112 бит безопасности. См. Раздел SP800-131A о цифровых сертификатах для получения дополнительной информации.
На мой взгляд, все сводится к следующему: ваш запас прочности «небольшой» с 512-битными ключами, «неплохой» с 1024-битными ключами и «неплохой» с 2048-битными ключами. Сделай немного анализ угроз и решить, каким должен быть запас прочности вашей организации, какие данные вы защищаете и что вы можете потерять, если криптосистема, защищающая их, сломается. Обязательно примите во внимание существующую политику и все юридические требования, которые вам необходимо соблюдать.