Sự khác biệt giữa id_rsa.pub và id_dsa.pub là gì?


Câu trả lời:


64

id_rsa.pubid_dsa.publà các khóa công khai cho id_rsaid_dsa.

Nếu bạn đang hỏi liên quan đến SSH, đó id_rsakhóa RSA và có thể được sử dụng với giao thức SSH 1 hoặc 2, trong khi đó id_dsalà khóa DSA và chỉ có thể được sử dụng với giao thức SSH 2. Cả hai đều rất an toàn, nhưng DSA dường như được tiêu chuẩn ngày nay (giả sử tất cả các máy khách / máy chủ của bạn hỗ trợ SSH 2).

Cập nhật: Vì điều này được viết nên DSA đã được chứng minh là không an toàn. Thông tin thêm có sẵn trong câu trả lời bên dưới.


Tôi phải không đồng ý với điều này. Ngày nay (và, mặc dù ở mức độ thấp hơn, cũng vào năm 2010 khi điều này được đăng), 1024 bit (kích thước khóa lớn nhất có sẵn cho DSA) được coi là quá yếu. Do đó, RSA là lựa chọn tốt hơn. Đối với SSH v1: Tôi đã không coi điều này là an toàn mười năm trước.
Adam Katz,

3
@AdamKatz DSA đã hỗ trợ hỗ trợ khóa 2048-bit và 3072-bit kể từ năm 2009 (theo FIPS 186-3 ). Hầu hết các máy khách / máy chủ ssh hỗ trợ các khóa DSA lớn hơn bao gồm OpenSSH và PuTTY. Hầu hết các trình tạo khóa cũng hỗ trợ các khóa DSA lớn hơn, nhưng ssh-keygen từ OpenSSH vẫn không (mặc dù cả ssh và sshd đều có). Đối với Linux, bạn có thể tạo các khóa DSA lớn hơn bằng OpenSSL như được mô tả trong bài đăng trên blog này .
Mike Pelley

1
Hấp dẫn! Tôi đã không biết điều đó, và điều đó chắc chắn giúp cân bằng trường giữa hai (mặc dù việc thiếu hỗ trợ OpenSSH là khá tệ). Tuy nhiên, tôi sẽ không nói rằng DSA là tiêu chuẩn (hiện tại hoặc trong năm 2010), trong khi RSA hoàn toàn là (và chúng tôi đang chuyển sang hệ thống đường cong elip như Ed25519).
Adam Katz

46

SSH sử dụng các cặp khóa công khai / riêng tư , khóa cá nhân RSAid_rsa của bạn (dựa trên số nguyên tố) cũng vậy, sẽ an toàn hơn khóa riêng DSA của bạn (dựa trên số mũ). Giữ các khóa riêng tư của bạn an toàn và chia sẻ rộng rãi các khóa công khai và của bạn .id_dsa id_rsa.pubid_dsa.pub

DSA không an toàn

DSA có một tham sốthể đoán được nếu trình tạo số ngẫu nhiên của máy tính của bạn là mệnh giá phụ, điều này sẽ tiết lộ khóa bí mật của bạn. ECDSA (nâng cấp đường cong elip của DSA) cũng dễ bị tổn thương tương tự . Ngay cả với những số ngẫu nhiên tốt, DSA cũng có những mối quan tâm về sức mạnh khácPDF (những điều này cũng được tìm thấy trong Diffie-Hellman ).

OpenSSH tạo ra các khóa 1024 bit không an toàn ( giải pháp thay thế ) và giờ sẽ tắt DSA theo mặc định .

Sử dụng Ed25519 khi có thể

Mật mã đường cong elliptic cung cấp độ phức tạp tăng lên với kích thước khóa nhỏ hơn. Ed25519 (dựa trên độ phức tạp của các đường cong elip được mô hình hóa bằng máy bay ) là cách triển khai được ưa thích hơn do giả định là thiếu can thiệp (các tài liệu bị rò rỉ cho thấy NSA của Hoa Kỳ làm suy yếu các tiêu chuẩn tiền điện tử ).

Thật không may, Ed25519 vẫn còn khá mới, yêu cầu OpenSSH 6.5 hoặc GnuPG 2.1 (xem danh sách đầy đủ ).

Sử dụng RSA với 4096 bit khi Ed25519 không khả dụng

Kích thước khóa RSA là 4096 bit nên có độ phức tạp tương đương với Ed25519.

Ed25519 vẫn được ưa thích hơn RSA do lo ngại rằng RSA có thể dễ bị tổn thương bởi các mối quan tâm về sức mạnh tương tự như DSA, mặc dù việc áp dụng cách khai thác đó cho RSA dự kiến ​​sẽ khó hơn đáng kể.


2
Chỉ một lần chỉnh sửa: DSA đã hỗ trợ các khóa 2048-bit và 3072-bit kể từ năm 2009 (theo FIPS 186-3 ). Thông tin thêm trong bình luận của tôi ở trên.
Mike Pelley

2
Infosec SE có một câu trả lời tuyệt vời cho câu hỏi đi sâu hơn này. Nó trích dẫn một cuộc nói chuyện năm 2013 của Black Hat cho thấy DSA không còn an toàn, ngay cả ở kích thước khóa lớn hơn.
Adam Katz

2
Tôi đã cập nhật câu trả lời này để toàn diện hơn về các vấn đề với DSA. Bây giờ nó chi tiết hơn câu trả lời Infosec SE (hợp lệ như nhau). Thậm chí còn chi tiết hơn khi bạn di chuột qua một số liên kết.
Adam Katz

1
Bài đăng này đã dạy tôi rất nhiều, cần nhiều ủng hộ hơn nữa.
liljoshu


1

rsa được coi là an toàn hơn.

Không còn nữa (tháng 5 năm 2020, mười năm sau), với OpenSSH 8.2 , như báo cáo của Julio

Thông báo ngừng sử dụng trong tương lai

Giờ đây, có thể 1 thực hiện các cuộc tấn công tiền tố đã chọn chống lại thuật toán băm SHA-1 với giá dưới 50 nghìn USD.
Vì lý do này, chúng tôi sẽ vô hiệu hóa thuật toán chữ ký khóa công khai "ssh-rsa" phụ thuộc vào SHA-1 theo mặc định trong bản phát hành trong tương lai gần .

(Xem " SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust " Leurent, G và Peyrin, T (2020))

Thật không may, thuật toán này vẫn được sử dụng rộng rãi mặc dù đã tồn tại các giải pháp thay thế tốt hơn, là thuật toán chữ ký khóa công khai duy nhất còn lại được chỉ định bởi các SSH RFC ban đầu.

Các lựa chọn thay thế tốt hơn bao gồm:

  • Các thuật toán chữ ký RFC8332 RSA SHA-2 rsa-sha2-256 / 512.
    Các thuật toán này có ưu điểm là sử dụng cùng loại khóa với " ssh-rsa", nhưng sử dụng thuật toán băm SHA-2 an toàn.
    Chúng đã được hỗ trợ kể từ OpenSSH 7.2 và đã được sử dụng theo mặc định nếu máy khách và máy chủ hỗ trợ chúng.

  • Thuật toán chữ ký ssh-ed25519.
    Nó đã được hỗ trợ trong OpenSSH kể từ bản phát hành 6.5.

  • Các thuật toán ECDSA RFC5656: ecdsa-sha2-nistp256/384/521.
    Chúng đã được OpenSSH hỗ trợ kể từ bản phát hành 5.7.

Để kiểm tra xem máy chủ có đang sử dụng thuật toán khóa công khai ssh-rsa yếu để xác thực máy chủ hay không, hãy thử kết nối với nó sau khi xóa ssh-rsathuật toán khỏi danh sách được phép của ssh (1):

ssh -oHostKeyAlgorithms=-ssh-rsa user@host

Nếu xác minh khóa máy chủ không thành công và không có loại khóa máy chủ được hỗ trợ nào khác, thì phần mềm máy chủ trên máy chủ đó phải được nâng cấp.

Bản phát hành OpenSSH trong tương lai sẽ bật UpdateHostKeystheo mặc định để cho phép máy khách tự động chuyển sang các thuật toán tốt hơn.
Người dùng có thể xem xét kích hoạt tùy chọn này theo cách thủ công .


-8

Một sử dụng DSA và một sử dụng RSA .


giả sử bạn chỉ đang sử dụng các tên mặc định (về mặt logic trông giống như vậy), nhà hát đã đánh nó ngay vào đầu.
David Larrabee

Bạn đã không trả lời phần thực của câu hỏi: cái nào an toàn hơn. Từ chối vì đây là câu trả lời hàng đầu. Không cần phải được.
akauppi
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.