Яка різниця між id_rsa.pub та id_dsa.pub?


Відповіді:


64

id_rsa.pubі id_dsa.pubє відкритими ключами для id_rsaі id_dsa.

Якщо ви запитуєте стосовно SSH, id_rsaце ключ RSA і може використовуватися з протоколом SSH 1 або 2, тоді id_dsaяк ключ DSA може використовуватися лише з протоколом SSH 2. Обидва вони дуже безпечні, але DSA, схоже, є стандарт на сьогодні (припускаючи, що всі ваші клієнти / сервери підтримують SSH 2).

Оновлення: Оскільки це було написано, DSA виявилося небезпечним. Більше інформації можна знайти у відповіді нижче.


Я повинен не погодитися з цим. Сьогодні (і, хоча і в меншій мірі, також у 2010 році, коли це було розміщено), 1024 біти (найбільший розмір ключа, доступний для DSA), вважається занадто слабким. Тому RSA - кращий варіант. Щодо SSH v1: Я не вважав це безпечним десять років тому.
Адам Кац,

3
@AdamKatz DSA підтримує підтримку 2048-розрядних та 3072-розрядних ключів з 2009 року (згідно з FIPS 186-3 ). Більшість клієнтів / серверів ssh підтримують більші ключі DSA, включаючи OpenSSH та PuTTY. Більшість генераторів ключів також підтримують більші ключі DSA, але ssh-keygen з OpenSSH все ще не підтримує (хоча і ssh, і sshd це роблять). Для Linux ви можете генерувати більші ключі DSA за допомогою OpenSSL, як описано в цьому дописі в блозі .
Mike Pelley,

1
Цікаво! Я цього не знав, і це, безумовно, допомагає вирівняти поле між ними (хоча відсутність підтримки OpenSSH є досить страшною). Тим не менше, я б не сказав, що DSA є стандартом (або зараз, або в 2010 році), тоді як RSA абсолютно є (і ми переходимо до еліптичних кривих систем, таких як Ed25519).
Адам Кац,

46

SSH використовує пари відкритого / приватного ключів , а id_rsaтакож ваш приватний ключ RSA (на основі простих чисел), який є більш безпечним, ніж ваш приватний ключ id_dsa DSA (на основі показників). Тримайте ваші особисті ключі безпечно і ділитися своїми id_rsa.pubі id_dsa.pubвідкриті ключі широко.

DSA небезпечний

DSA має параметр, який можна вгадати, якщо генератор випадкових чисел вашого комп’ютера є нижчим, що відкриє ваш секретний ключ. ECDSA (АППИ еліптичної кривої поновлення) є так само вразлива . Навіть при хороших випадкових числах DSA має інші проблеми щодо силиPDF (вони також є у Діффі-Хеллмана ).

OpenSSH створює небезпечні 1024-бітові ключі ( обхідний шлях ) і тепер за замовчуванням вимикає DSA .

Використовуйте Ed25519, коли це можливо

Криптографія еліптичної кривої пропонує підвищену складність із меншими розмірами ключів. Ed25519 (заснований на складності плоскомодельованих еліптичних кривих ) є кращим варіантом реалізації через передбачувану відсутність втручання (документи, що просочуються, показують, що АНБ США послаблює крипто-стандарти ).

На жаль, Ed25519 все ще досить новий, що вимагає OpenSSH 6.5 або GnuPG 2.1 (див. Повний список ).

Використовуйте RSA з 4096 бітами, коли Ed25519 недоступний

Розміри ключів RSA 4096 біт повинні мати складність, порівнянну з Ed25519.

Ed25519 все ще віддають перевагу RSA через побоювання, що RSA може бути вразливим до тих самих проблем, що і DSA, хоча застосовувати цей експлойт до RSA, як очікується, буде значно складніше.


2
Лише одне виправлення: DSA підтримує 2048-бітні та 3072-бітні ключі з 2009 року (згідно з FIPS 186-3 ). Більше інформації в моєму коментарі вище.
Mike Pelley

2
Infosec SE має приємну відповідь на це питання, яка йде більш глибоко. У ньому цитується виступ Black Hat 2013, який передбачає, що DSA більше не захищений, навіть при більших розмірах ключів.
Адам Кац

2
Я оновив цю відповідь, щоб бути більш вичерпною щодо проблем із DSA. Зараз він більш детальний, ніж (однаково дійсний) відповідь Infosec SE. Якщо навести вказівник миші на деякі посилання, є ще більше деталей.
Адам Кац

1
Цей пост мене навчив так багато, потребує набагато більше голосів.
liljoshu


1

RSA вважається більш безпечним.

Чи не більше (травень 2020 року, десять років по тому), з OpenSSH 8.2 , як і повідомлялося на Хуліо

Повідомлення про застаріле майбутнє

Тепер можна 1 виконувати атаки з обраним префіксом проти алгоритму хешування SHA-1 менш ніж за 50 тис. Доларів США.
З цієї причини ми вимкнемо алгоритм підпису відкритого ключа "ssh-rsa", який за замовчуванням залежить від SHA-1 у найближчому майбутньому випуску .

(Див. " SHA-1 - це розбіжність: Перше зіткнення обраного префіксу на SHA-1 та застосування до мережі PGP Web of Trust " Леран, Г. і Пейрін, Т (2020))

На жаль, цей алгоритм досі широко використовується, незважаючи на існування кращих альтернатив, будучи єдиним алгоритмом підпису з відкритим ключем, що залишився, визначеним оригінальними RFC SSH.

Кращі альтернативи включають:

  • Алгоритми підпису RFC8332 RSA SHA-2 rsa-sha2-256 / 512.
    Ці алгоритми мають перевагу у використанні того самого типу ключа, що і " ssh-rsa", але використовують безпечні алгоритми хешування SHA-2.
    Вони підтримуються з OpenSSH 7.2 і вже використовуються за замовчуванням, якщо клієнт і сервер їх підтримують.

  • Алгоритм підпису ssh-ed25519.
    Він підтримується в OpenSSH з випуску 6.5.

  • Алгоритми ECDSA RFC5656: ecdsa-sha2-nistp256 / 384/521.
    Вони підтримуються OpenSSH з випуску 5.7.

Щоб перевірити, чи використовує сервер слабкий алгоритм відкритого ключа ssh-rsa для автентифікації хосту, спробуйте підключитися до нього, видаливши ssh-rsaалгоритм із дозволеного списку ssh (1):

ssh -oHostKeyAlgorithms=-ssh-rsa user@host

Якщо перевірка ключа хосту не вдається, і немає інших підтримуваних типів ключів хосту, серверне програмне забезпечення на цьому хості слід оновити.

Майбутній випуск OpenSSH дозволить UpdateHostKeysза замовчуванням дозволити клієнту автоматично переходити на кращі алгоритми.
Користувачі можуть розглянути можливість увімкнення цієї опції вручну .


-8

Один використовує DSA, а другий - RSA .


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

Ви не відповіли на реальну частину запитання: що є більш безпечним. Голосування проти, оскільки це була найвища відповідь. Не потрібно.
akauppi
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.