연산 비용이 낮아 대량 데이터 암호화에 적합합니다. AES, ChaCha20 같은 알고리즘이 대표적이며, 비대칭키보다 수십-수백 배 빠릅니다.

단점은 key 배포 문제입니다. 처음 만나는 두 당사자가 같은 key를 안전하게 공유할 방법이 없습니다. 이 문제를 해결하기 위해 비대칭키 방식이 등장했습니다.

Diffie-Hellman key exchange를 씁니다. 두 당사자가 공개 채널에서 각자의 값을 교환하고, 수학적 연산을 통해 제3자는 도출할 수 없지만 양쪽은 같은 비밀값에 도달하게 됩니다. 실제로 TLS는 ECDHE(타원 곡선 기반 Diffie-Hellman)를 많이 씁니다.

대표적인 비대칭키 알고리즘입니다. 큰 수를 두 소수의 곱으로 만드는 건 쉽지만, 반대로 큰 수를 소인수 분해하는 건 어렵다는 수학적 성질을 이용합니다.

public key로 암호화하면 private key로만 복호화할 수 있고, private key로 서명하면 public key로 검증할 수 있습니다. key 길이는 2048-bit 이상을 권장합니다. 2048-bit는 2^2048 ≈ 10^616(자릿수가 616개)의 경우의 수로, 현재 컴퓨터로 현실적인 시간 안에 인수분해할 수 없습니다.

다만 연산 비용이 높아 TLS에서는 key 교환에 RSA 대신 ECDHE를 주로 쓰고, RSA는 인증서 서명에 주로 사용합니다. ECDHE는 Diffie-Hellman key exchange를 타원 곡선으로 구현한 변형으로, 더 짧은 key로 동등한 보안을 제공하고 매 세션마다 임시 key를 생성해 forward secrecy도 지원합니다.

공개 채널에서 도청자 없이 공통 비밀을 만드는 방법입니다.

1. 공개 값 g, p를 합의합니다. (누가 봐도 됩니다)
2. Alice는 비밀 a를, Bob은 비밀 b를 각자 선택합니다.
3. Alice는 g^a mod p를, Bob은 g^b mod p를 서로에게 전송합니다.
4. Alice는 받은 값에 a를 적용하고, Bob은 받은 값에 b를 적용하면 양쪽 모두 g^ab mod p에 도달합니다.

도청자는 g^a mod p와 g^b mod p를 봐도 a나 b를 역산할 수 없어 공통 비밀을 구하지 못합니다. 이를 이산 로그 문제라고 합니다.

ECDHE는 이 원리를 타원 곡선 위에서 구현한 변형으로, 더 짧은 key로 같은 어려움을 제공합니다.

공개하도록 설계된 key입니다. 누구나 public key로 암호화하거나 서명을 검증할 수 있습니다. 다만 그 public key가 정말 대상의 것인지 인증서 같은 방식으로 검증해야 합니다.

private key가 유출되면 암호화된 메시지를 복호화하거나 서명을 위조할 수 있게 됩니다. 신원과 기밀성을 지키는 핵심 비밀이며, 유출되면 해당 key 쌍 전체를 폐기하고 재발급해야 합니다.

암호화는 내용을 숨기는 목적이고, 전자서명은 누가 만들었는지와 내용이 바뀌지 않았는지를 검증하는 목적입니다.

서명 흐름은 다음과 같습니다. 서명자가 내용의 해시를 private key로 암호화해 서명을 만들고, 수신자는 public key로 서명을 복호화해 해시를 구한 뒤 내용의 해시와 비교합니다. 해시가 일치하면 내용이 바뀌지 않았고, 해당 private key 소유자가 서명한 것임을 확인할 수 있습니다.

브라우저가 bank.com에 접속하면 서버가 public key를 보내줍니다. 그런데 이 public key가 진짜 bank.com의 것인지 알 수 없습니다. 공격자가 중간에서 자신의 public key를 대신 보내면(MITM), 사용자는 공격자의 key로 암호화하게 되어 내용이 노출됩니다.

인증서는 이를 막기 위해 CA가 "이 public key는 진짜 bank.com의 것"임을 서명으로 보증하는 문서입니다. private key가 아닌 public key를 담는 이유는, 인증서의 목적이 public key를 신뢰할 수 있게 배포하는 것이기 때문입니다. 인증서에는 public key, 발급 대상 도메인, 유효 기간, CA의 서명이 담겨 있습니다.

Certificate Authority의 약자로, 인증서를 발급하고 서명하는 신뢰할 수 있는 기관입니다. 브라우저나 OS는 신뢰할 수 있는 CA 목록을 미리 가지고 있어, 그 CA가 서명한 인증서를 신뢰합니다.

CA는 계층 구조를 이룹니다. 최상위 Root CA가 중간 CA에 서명하고, 중간 CA가 실제 서비스 인증서에 서명하는 chain of trust 형태입니다. 브라우저는 이 chain을 따라 Root CA까지 검증합니다.

비대칭키는 안전한 key 합의와 신원 인증에 적합하지만 느립니다. 대칭키는 빠르지만 key 배포 문제가 있습니다. TLS는 handshake 단계에서 비대칭키로 session key를 합의하고, 이후 실제 데이터는 그 session key로 대칭 암호화합니다. 두 방식의 장점을 조합한 구조입니다.

TLS 1.3 기준으로, 클라이언트가 지원하는 암호화 방식 목록을 보내면 서버가 방식을 선택하고 인증서를 전달합니다. 클라이언트는 인증서를 CA chain으로 검증한 뒤, ECDHE로 양측이 동일한 session key에 도달합니다. 이후 통신은 그 session key로 대칭 암호화됩니다. TLS 1.3은 1-RTT로 handshake를 마칩니다.

과거의 암호화된 트래픽이 나중에 private key가 유출되더라도 복호화되지 않는 성질입니다.

ECDHE처럼 매 세션마다 새로운 임시 key 쌍을 생성하는 방식으로 달성합니다. session key가 장기 private key와 독립적으로 만들어지기 때문에, 서버의 private key가 유출되어도 과거 트래픽을 소급해서 복호화할 수 없습니다. TLS 1.3은 forward secrecy를 지원하지 않는 cipher suite를 아예 제거했습니다.

TLS 위에서 동작합니다. handshake 시 비대칭키로 인증과 key 교환을 수행하고, 이후 통신은 AES-GCM이나 ChaCha20 같은 대칭키 암호화로 데이터를 주고받습니다.