Яку довжину ключа RSA я повинен використовувати для своїх сертифікатів SSL?


95

Я зараз створюю КСВ, і мені цікаво, яка, можливо, найкраща довжина для мого ключа RSA.

Звичайно, 384, ймовірно, занадто слабкий, а 16384 - ймовірно, занадто повільний.

Чи існує консенсус щодо довжини ключа, яку слід використовувати, залежно від терміну служби сертифіката?

Редагувати: Як і більшість людей, я хочу, щоб мій ключ був досить сильним. Мене не турбує те, що АНБ може зламати мій ключ у 2019 році. Я просто хочу знати, яка найкраща практика, коли планується вести звичайний бізнес (наприклад, сайт електронної комерції)

Відповіді:


102

Станом на 2020 рік, ключі RSA мають становити 2048 біт.

1024 біт

  • 1024 біти сертифікати RSA застарілі та не приймаються браузерами.
  • У 2014 році Firefox перестав приймати сертифікати RSA 1024 біт.
  • Органи сертифікації припинили доставку сертифікатів RSA 1024 біт у 2014 році чи раніше. Див . Повідомлення GlobalSign або Comodo .
  • 1024-бітові ключі застаріли, оскільки їх можна було зламати, отримавши невеликий центр обробки даних (тисячі процесорів або сотні графічних процесорів, можливо, за кілька місяців). Це може здатися багато, але це було в межах досяжності будь-якої великої організації чи уряду.

2048 біт

  • 2048 біт сертифікатів RSA в даний час є прийнятою нормою для використання.
  • Базова лінія за замовчуванням постачається CA та використовується програмним забезпеченням.
  • Врешті-решт теж зламається. Не знаю, коли, але може пройти десятиліття.
  • Подвоєння розміру вимагає набагато більшої кількості порядків, щоб обчислити потужність. Дивіться питання, наскільки сильніший RSA 2048 порівняно з 1024 .

4096 біт

  • Наступним кроком є ​​4096 біт сертифікатів RSA
  • Широко доступні та підтримувані. Всі основні CA можуть надавати як 2048, так і 4096 біт RSA, включаючи давайте шифруємо .
  • Обчислювальна вартість не є лінійною за розміром ключа. 4096 не вдвічі повільніший за 2048 рік, це може бути в 10 разів повільніше для обробки. Не оновлюйте сертифікати наосліп до 4096 біт, не враховуючи вплив продуктивності .
  • "Веб" в основному залишається на 2048 бітах сертифікатів, оскільки він не може нести вартість апаратних засобів на 4096 біт. Розгляньте таких великих акторів, як Google, CloudFlare, NetFlix з величезним трафіком та обладнанням.

3072 біт

  • 3072 біта - це не річ. Перейти прямо до 4096 біт.
  • Цілком можливо зробити 3072 біт криптографії, це просто те, що жодне програмне забезпечення насправді не реалізує, підтримує та рекламує її офіційно.
  • Історично в минулому 2010-2015 роках була спроба запустити 3072 для випадків використання, коли додаткові обчислювальні витрати 4096 не є ідеальними. Він згас, але є ще старі статті, які поширюють переваги (швидшого) 3072 року.

Додатково

  • RSA був вперше публічно описаний у 1977 році, і він все ще сильний майже через 50 років. Просто потрібно збільшити кількість бітів, щоб не відставати від швидших комп'ютерів.
  • Існує ще один метод криптографії відкритого ключа, заснований на еліптичних кривих, див. ECDSA (1992).
  • Існує величезний розрив між можливостями користувача та зловмисника. Веб-сервер або мобільний клієнт мають один процесор (малопотужний). Зловмисник може мати цілий центр обробки даних, для довідки новоспечений центр обробки даних AWS розміщує близько 60 000 серверів.
  • Неймовірно, що один мобільний пристрій може обчислити математику за кілька секунд ... про те, що мільйони комп'ютерів не могли мріяти здогадуватися протягом життя.

13
Відмінності ("256-бітний буде працювати назавжди" з одного боку, а "1024-бітове вже лайно" з іншого) обумовлені різницею між симетричними та асиметричними алгоритмами та видами ключів, що використовуються в кожному. З будь-яким заданим "еквівалентним рівнем безпеки" ви побачите дуже різні необроблені цифри для довжини ключів у симетричній та асиметричній.
Ti Strga

1
Станом на вересень 2015 року, схоже, галузь перейшла на не прийняття менше 2048-бітних КСВ. Дивіться нижче відповіді та статтю підтримки Comodo
angularsen

2
@anjdreas, Хоча це правда, що 2048 рік - це мінімальний мінімум , я буду дуже обережно цитувати пункти зі статей CA.
Pacerier

Лабораторія RSA - це 404, btw
Jocull

1
Примітка: повністю переписав відповідь через 11 років з актуальними рекомендаціями та посиланнями. коментарі вище тут коментували попередні зміни.
користувач5994461

12

Оскільки багато клієнтів вимагають дотримання криптографічних стандартів NIST, я використовую вказівки у Спеціальній публікації NIST 800‑57, Рекомендації щодо керування ключами, частина 1, §5.6. Більшість наших додатків добре підходять для 112 "біт" безпеки, так що це відповідає потрійному DES (або невеликому удару до 128-бітового AES) для симетричних шифрів і 2048-бітного ключа для RSA. Приблизну еквівалентність див. У таблиці 2.

Дійсні чи ні, можливість пересилати їх до публікації NIST допомагає клієнтам краще почуватися щодо безпеки (якщо вони намагаються запитати).


Стаття, згадана у цій відповіді, переглядається до Рекомендації щодо управління ключовими словами : Частина 1: Загальне (редакція 3) . Поточна редакція - липень 2012
AaA

Я бачу, що сторінку NIST було знято та замінено повідомленням: "Через проміжок у державному фінансуванні csrc.nist.gov та всі пов’язані з цим заходи в Інтернеті будуть недоступними до подальшого повідомлення".
ву-лі

Існує ця сторінка, яка порівнює деякі основні рекомендації щодо
wu-lee

10

Органи сертифікації не підписуватимуть csrs розміром менше 2048 біт, тому вам слід створити csr у розмірі 2048 біт.


6
[цитування потрібне]
CodesInChaos

2
Джерело - answers.ssl.com/877 / ... - деякі центри сертифікації , як Affirmtrust / Trend Micro вже вбудовування 4096 біт коріння , тому ми, швидше за все , перемикатися ті , в найближчі роки
йог

Я просто спробував Comodo, і вони не приймають менше 2048 біт .
angularsen

7

Наступного серпня Microsoft планує розгорнути патч на сервер 2003/2008, Win7, який вимагатиме використання мінімально 1024-бітного ключа RSA. Тож ви можете також почати робити цей "найменший мінімум" стандартом.


6

Для сертифікатів SSL, які використовуються на веб-сайтах, важливо зазначити цей текст із веб-сайту Thawte.com (станом на 2014-07-22):

Галузеві стандарти, встановлені Форумом із сертифікації / Веб-переглядача (CA / B), вимагають, щоб сертифікати, видані після 1 січня 2014 року, ОБОВ'ЯЗКОВО повинні мати принаймні 2048-бітну довжину ключа.


Mouais, Facebook все ще на 256 ключах довжина => b3.ms/XmWn0e1BMYOk
Томас Деко

Для уточнення Facebook не використовує RSA, він використовує ECDHE_ECDSA, отже, менша довжина ключа.
Майкл

5

Мені потрібно було створити кілька нових сертифікатів SSL, і я не був задоволений відповідями вище, тому що вони здавалися розпливчастими або застарілими, тому я трохи копав. Знизу в обраній відповіді є правильне використання "2048-бітних клавіш ... довше безглуздо" .

Збільшення довжини біта до 4096 додає вашому серверу потенційно значуще навантаження (залежно від наявного навантаження), пропонуючи в основному незначне оновлення безпеки

Якщо ви перебуваєте в ситуації, коли вам потрібно більше 2048-бітного ключа, вам не потрібна більша довжина бітів, вам потрібен новий алгоритм


1

Я думаю, що 4096 нормально для RSA

Перевірте це посилання

Кінець підпису SHA-1 - нічого нового, але Google прискорив процес хромування. У наступні кілька тижнів слід перевірити їх SSL-сертифікати.

Це може бути корисним


1
Чи можете ви також розмістити посилання на англійській мові? Моя німецька досить слабка.
Вай Ха Лі

Де-юро, ключі RSA можуть мати довжину лише 1024, 2048 або 3072 біт (згідно PKCS №1 2.2 та FIPS 186-4).
апрель

Полум'я показало, що зловмисники атакують хеш, а не більший модуль. Якщо ви використовуєте SHA-1, ви можете також використовувати 1024-бітовий модуль, оскільки хеш і модуль забезпечують рівноцінну безпеку. 1024-бітний модуль забезпечить швидші операції, ніж великий 4096-модуль.
jww

0

4
Не зовсім. Рекомендація щодо короткострокового (принаймні десяти років) - 3072. RSA 15360 - це довгостроковий (тридцять-п’ятдесят років) і має сенс лише у тому випадку, якщо ви розраховуєте, що зможете зберегти приватний ключ у таємниці так довго.
Генрік Хеллстрьом
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.