В чем разница между 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, как описано в этом сообщении блога .
Майк Пелли,

1
Интересно! Я не знал об этом, и это, безусловно, помогает уравновесить поле между ними (хотя отсутствие поддержки OpenSSH ужасно). Тем не менее, я бы не сказал, что DSA является стандартом (сейчас или в 2010 году), в то время как RSA - безусловно (и мы переходим к системам с эллиптическими кривыми, таким как Ed25519).
Адам Кац

46

SSH использует пары открытого / закрытого ключей , id_rsaкак и ваш закрытый ключ RSA (на основе простых чисел), который более безопасен, чем ваш закрытый ключ id_dsa DSA (на основе показателей степени). Храните свои закрытые ключи в безопасности и делитесь своими id_rsa.pubи id_dsa.pubобщедоступными ключами широко.

DSA небезопасен

DSA имеет предполагаемый параметр, если генератор случайных чисел на вашем компьютере не соответствует номиналу, который покажет ваш секретный ключ. ECDSA (обновление эллиптической кривой DSA) также уязвимо . Даже с хорошими случайными числами у 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 ). Более подробная информация в моем комментарии выше.
Майк Пелли,

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

2
Я обновил этот ответ, чтобы подробнее рассказать о проблемах с DSA. Теперь он более подробный, чем ответ Infosec SE. Когда вы наводите указатель мыши на некоторые ссылки, появляется еще больше деталей.
Адам Кац

1
Этот пост многому меня научил, нужно гораздо больше голосов.
liljoshu

2

rsa считается более безопасным.

Не больше (май 2020, десять лет спустя), с OpenSSH 8.2 , как и сообщалось на Хулио

Уведомление о будущем прекращении поддержки

Теперь можно 1 выполнять атаки с выбранным префиксом против хеш-алгоритма SHA-1 менее чем за 50 тыс. Долларов США.
По этой причине в ближайшем будущем мы отключим алгоритм подписи открытого ключа «ssh-rsa», который по умолчанию зависит от SHA-1 .

(См. « SHA-1 - это беспорядки: конфликт первого выбранного префикса в SHA-1 и приложение к сети доверия PGP » Лоран, Дж. И Пейрин, Т. (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 .


при условии, что вы просто используете имена по умолчанию (которые логически выглядят так), theatrus ударил его прямо по голове.
Дэвид Ларраби,

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