Mã hóa bất đối xứng RSA/ECC: Public Key, Private Key trong HTTPS và SSH
Hướng dẫn mã hóa bất đối xứng RSA/ECC: cách tạo public-private key, RSA-OAEP/PSS, ECDSA/ECDH, HTTPS TLS 1.3, SSH và key management an toàn.
ShanverseUpdated 12 min read— viewsLoading views
Cryptography
HTTPS & TLS
Mã hóa bất đối xứng là gì?
Hệ mật bất đối xứng tạo một cặp khóa có quan hệ toán học:
Private Key: giữ bí mật, dùng để ký hoặc thực hiện phần bí mật của key agreement/decryption.
Public Key: có thể phân phối, dùng để verify chữ ký, mã hóa theo scheme phù hợp hoặc tham gia key agreement.
Từ public key phải cực kỳ khó suy ra private key với máy tính cổ điển và tham số an toàn.
Public key không cần bí mật, nhưng phải được xác thực danh tính. Nếu attacker thay public key của server bằng key của họ, toán học vẫn đúng nhưng bạn đang nói chuyện với sai người.
Bất đối xứng và đối xứng
Hệ thống hiện đại kết hợp cả hai theo
Comments
hybrid cryptography
.
Ba khái niệm dễ bị trộn
Encryption
Public key encryption cho phép người gửi mã hóa dữ liệu nhỏ bằng public key; holder của private key giải mã. Với RSA phải dùng scheme như RSA-OAEP, không dùng raw/textbook RSA.
Digital Signature
Private key tạo chữ ký trên message/hash; public key verify. Đây không nên được mô tả là “mã hóa bằng private key”. Signature có encoding, hashing và security definition riêng, ví dụ RSA-PSS, ECDSA hoặc Ed25519.
Key Agreement
Hai bên đóng góp key material để suy ra shared secret mà không gửi secret trực tiếp. ECDH/X25519 là key agreement, không phải encryption algorithm cho arbitrary payload.
RSA hoạt động thế nào?
RSA dựa trên arithmetic modulo một số composite lớn.
Key generation đơn giản hóa
Chọn hai prime ngẫu nhiên lớn p, q.
Tính n = p × q.
Tính λ(n) = lcm(p - 1, q - 1) hoặc dùng biểu diễn tương đương.
Chọn public exponent e, thường là 65537, sao cho coprime với λ(n).
Tính d = e⁻¹ mod λ(n).
Phép RSA lõi:
Security thực tế dựa vào độ khó phân tích n thành p × q với key đủ lớn, cộng với padding/scheme được thiết kế đúng.
RSA Encryption và Signature
RSA-OAEP cho encryption
OAEP thêm randomness và cấu trúc bảo mật. RSA chỉ mã hóa message ngắn hơn modulus trừ overhead padding, nên không dùng để mã hóa file lớn.
Mô hình envelope encryption:
RSA-PSS cho signature
PSS là signature encoding hiện đại. Private key ký, public key verify. Không dùng RSA-OAEP để ký và không dùng RSA-PSS để mã hóa.
ECC hoạt động thế nào?
Elliptic Curve Cryptography làm việc trên nhóm điểm của một đường cong trên finite field. Dạng minh họa phổ biến:
Một curve an toàn có:
Field và curve parameters.
Base point G.
Order n của subgroup.
Quy tắc cộng điểm và scalar multiplication.
Key generation:
Từ d tính Q hiệu quả; từ Q tìm d được cho là khó với tham số đúng—đây là Elliptic Curve Discrete Logarithm Problem.
Không tự chọn curve tùy ý. Dùng named curve/algorithm được thư viện và protocol hỗ trợ.
ECC là một họ, không phải một thuật toán
ECDSA: chữ ký số trên elliptic curve.
ECDH/ECDHE: key agreement; chữ E cuối là ephemeral trong ngữ cảnh protocol.
Ed25519: signature scheme dựa trên Edwards curve, có API và encoding riêng.
X25519: Diffie-Hellman key agreement trên Curve25519.
Ed25519 không phải encryption algorithm. X25519 không tạo signature. Không hoán đổi key/algorithm chỉ vì cùng dùng “25519”.
RSA và ECC khác nhau thế nào?
Không có “ECC luôn nhanh hơn” cho mọi operation, library và phần cứng. Đo trên workload thật và ưu tiên interoperability/policy.
Kích thước khóa và security strength
Các mức gần đúng thường dùng:
NIST SP 800-131A Rev. 2 chấp nhận RSA signature generation từ 2048-bit và ECDSA/EdDSA có subgroup order từ 224-bit cho mức ít nhất 112-bit. Chính sách tổ chức, thời hạn bảo vệ dữ liệu, compliance và protocol support có thể yêu cầu mạnh hơn.
Không so sánh “RSA 256-bit” với “ECC 256-bit” theo độ dài số đơn thuần; chúng dựa trên bài toán toán học khác nhau.
HTTPS/TLS thực sự dùng key thế nào?
TLS 1.3 tách hai vai trò:
Certificate authentication: server chứng minh danh tính bằng signature key trong certificate—có thể là RSA hoặc ECDSA tùy hệ sinh thái.
Ephemeral key exchange: client/server dùng DHE/ECDHE key share để tạo shared secret có forward secrecy.
Luồng đơn giản hóa:
Mermaid
Loading diagram…
RFC 8446 yêu cầu signature_algorithms cho certificate authentication và key_share cho DHE/ECDHE. Static RSA key exchange không còn trong TLS 1.3. RSA certificate key có thể ký handshake; nó không trực tiếp giải mã toàn bộ traffic.
Forward Secrecy
ECDHE/DHE dùng ephemeral private keys rồi xóa chúng. Nếu long-term certificate private key bị lộ sau này, attacker không thể chỉ dùng key đó để giải mã các phiên TLS 1.3 đã ghi lại—giả sử implementation, random và endpoint không bị compromise trong phiên.
Certificate Authority giải quyết gì?
Toán học chỉ chứng minh “holder biết private key tương ứng”. CA certificate chain gắn public key với hostname/identity.
Browser kiểm tra:
Chain đến trust anchor.
Signature của CA.
Hostname/SAN.
Thời gian hiệu lực.
Key usage và algorithm constraints.
Revocation/status theo cơ chế và policy của client.
Bỏ qua hostname/certificate validation làm TLS mất authentication dù encryption vẫn chạy.
SSH dùng key thế nào?
SSH có nhiều lớp key khác nhau:
Host Key
Server ký handshake để chứng minh identity. Client lưu fingerprint trong known_hosts hoặc xác minh qua SSH CA/DNS/policy.
User Authentication Key
User giữ private key; public key nằm trong authorized_keys hoặc certificate system. Client ký challenge/session data để chứng minh giữ private key—private key không được gửi lên server.
Key Exchange
SSH dùng KEX như curve-based Diffie-Hellman để tạo session secret, sau đó dùng symmetric cipher/MAC hoặc AEAD cho traffic.
ssh-rsa không đồng nghĩa mọi RSA key đều lỗi thời
Trong SSH, tên ssh-rsa lịch sử chỉ signature scheme RSA với SHA-1. OpenSSH đã disable scheme này mặc định; RSA key vẫn có thể dùng với rsa-sha2-256 hoặc rsa-sha2-512 nếu hai bên hỗ trợ.
Các lựa chọn hiện đại thường gồm:
Ed25519 cho môi trường hỗ trợ.
RSA với SHA-2 khi cần compatibility.
Hardware-backed FIDO keys như ed25519-sk/ecdsa-sk khi phù hợp.
Không bật lại ssh-rsa SHA-1 toàn cục chỉ để sửa một legacy host; ưu tiên upgrade hoặc cấu hình exception hẹp, có kế hoạch loại bỏ.
Sinh SSH Key an toàn
Ed25519:
RSA cho compatibility:
Đặt passphrase mạnh.
Không gửi private key.
Copy file .pub vào nơi cần authorize.
Xác minh fingerprint trước khi trust.
Dùng ssh-agent/hardware-backed key theo threat model.
-a tăng KDF rounds cho private-key passphrase protection; trade-off là thời gian unlock.
Sinh key bằng OpenSSL
RSA 3072-bit:
EC P-256:
Đừng để private PEM không mã hóa trên laptop/server nếu threat model yêu cầu passphrase, KMS hoặc HSM. Lệnh/config có thể khác theo OpenSSL version và compliance mode.
Sinh key trong Node.js
RSA:
EC P-256:
Trong production, ưu tiên API trả KeyObject, KMS/HSM hoặc non-exportable key thay vì giữ private key dạng string lâu trong memory/log.
Key Format: PEM không phải thuật toán
DER: binary encoding.
PEM: base64 DER với header/footer.
SPKI: format phổ biến cho public key.
PKCS#8: format generic cho private key.
PKCS#1: format RSA-specific legacy/common.
OpenSSH public/private format: format riêng của SSH tooling.
File có chữ “PEM” không cho biết key dùng RSA hay EC; phải inspect metadata/algorithm identifier.
Private Key phải được bảo vệ thế nào?
Sinh bằng CSPRNG của OS/thư viện chuẩn.
Không commit Git, không bake vào Docker image.
Không log key, passphrase hoặc decrypted PEM.
Dùng file permission tối thiểu, secret manager, KMS hoặc HSM.
Tách key theo environment, service và purpose.
Mã hóa backup và kiểm thử restore.
Rotation/revocation có runbook và audit.
Đặt expiration ngắn cho certificate khi có automation.
Theo dõi fingerprint/key ID thay vì copy key tùy tiện.
Xóa securely theo khả năng storage/hardware và threat model.
Những lỗi nguy hiểm
1. Raw/Textbook RSA
Không có OAEP/PSS và randomness phù hợp; không an toàn.
2. Dùng RSA để mã hóa file trực tiếp
RSA có payload limit và chậm. Dùng envelope encryption.
3. Reuse nonce trong ECDSA
Nonce k bị lặp hoặc dự đoán được có thể làm lộ private key. Dùng implementation chuẩn có deterministic nonce/secure RNG theo specification.
4. Tự viết curve/point validation
Invalid-point và side-channel bugs rất khó tránh. Dùng library/protocol được audit.
5. Cùng một key cho TLS, SSH, JWT và data encryption
Vi phạm key separation, làm blast radius lớn và gây algorithm/format confusion.
6. Public key không được xác thực
MITM thay public key. HTTPS dùng CA/hostname validation; SSH dùng host fingerprint/CA/known_hosts.
7. Private key nằm trong frontend
Code/browser bundle là môi trường người dùng kiểm soát. Không nhúng server signing key hoặc TLS private key vào client.
8. Không kiểm tra certificate/host key
Encryption không có identity authentication vẫn dễ bị MITM.
9. Hard-code passphrase bên cạnh private key
Tách secret và dùng secret manager/identity-based access.
10. Tuyên bố key “an toàn vĩnh viễn”
Security phụ thuộc thời gian, thuật toán, implementation, threat model và tiến bộ cryptanalysis/computing.
Side-Channel và Implementation Security
Toán học đúng chưa đủ. Implementation cần:
Constant-time operation ở nơi nhạy cảm.
RSA blinding và CRT fault protection.
Secure nonce/randomness.
Point/public-key validation.
Không để error/timing tạo padding oracle.
Zeroization/buffer lifetime theo khả năng runtime.
Dependency patching và test vector chuẩn.
JavaScript application code nên gọi Web Crypto, Node crypto, OpenSSL-backed library, platform KMS/HSM—không cài modular exponentiation hay curve arithmetic để bảo mật production.
RSA/ECC trước máy tính lượng tử
Máy tính lượng tử đủ mạnh chạy Shor có thể phá cả RSA và ECC. Điều đó không có nghĩa phải tự thay bằng thuật toán mới ngay lập tức, nhưng hệ thống nên có crypto agility:
Inventory key, certificate và protocol.
Tách algorithm identifier khỏi business data.
Hỗ trợ rotation/migration.
Theo dõi tiêu chuẩn post-quantum và hybrid deployments.
Đánh giá “harvest now, decrypt later” cho dữ liệu cần bí mật dài hạn.
Dùng implementation/standard đã được ecosystem hỗ trợ, không tự thiết kế hybrid scheme.
Checklist chọn thuật toán
HTTPS
Dùng TLS 1.3 khi có thể.
Certificate/key type phù hợp CA, client và compliance.
ECDHE/DHE key exchange và AEAD cipher suite.
Không cấu hình static RSA key exchange.
Tự động renew, protect private key và test chain/hostname.
SSH
Ed25519 cho hệ thống hiện đại hoặc RSA SHA-2 khi cần compatibility.
Không nhầm ssh-rsa SHA-1 với mọi RSA key.
Passphrase/hardware key theo threat model.
Verify host fingerprint; không tắt StrictHostKeyChecking bừa bãi.
Rotate/revoke key rời tổ chức hoặc bị lộ.
Application cryptography
Signature, encryption và key agreement dùng đúng primitive.
RSA-OAEP cho RSA encryption; RSA-PSS cho RSA signatures.
Envelope encryption cho payload lớn.
Named curve/algorithm chuẩn.
Key ID, algorithm và version đi cùng ciphertext/signature.
Có test failure, rotation và backward compatibility.
Kết luận
RSA và ECC tạo public/private key từ trapdoor mathematical problems:
Trong HTTPS và SSH, cặp key chủ yếu cung cấp authentication, signature và key agreement; symmetric session keys mới bảo vệ luồng dữ liệu lớn. TLS 1.3 không dùng static RSA key exchange, còn SSH phân biệt host key, user authentication key và ephemeral KEX.
Lựa chọn đúng không chỉ là “RSA hay ECC” mà còn là scheme, key size, protocol, compatibility và vòng đời key. Dùng thư viện chuẩn, bảo vệ private key, xác thực public key, triển khai rotation/audit và chuẩn bị crypto agility cho kỷ nguyên hậu lượng tử.
1Public key: (n, e)2Private key: d và thường giữ p, q cùng CRT parameters để tăng tốc
Codeplain text
1public operation: y = x^e mod n2private operation: x = y^d mod n
Codeplain text
11. Tạo random symmetric data key.22. Mã hóa dữ liệu bằng AES-GCM/ChaCha20-Poly1305.33. Wrap data key bằng RSA-OAEP public key.44. Lưu ciphertext + wrapped key + nonce + authentication tag.
Codeplain text
1Private key: random scalar d, 1 ≤ d < n2Public key: Q = dG
Codeplain text
1Host key → xác thực server2User key → xác thực user3KEX key material → tạo session keys4Symmetric keys → bảo vệ dữ liệu phiên
Vì sao raw SHA-256 không phù hợp để hash mật khẩu? So sánh MD5, SHA-256, Bcrypt, Argon2id và hướng dẫn password storage, migration, salt/pepper an toàn.
