ECC(타원 곡선 암호화)와 RSA는 SSL 인증서 키 쌍을 생성하는 데 사용되는 두 가지 알고리즘입니다. 둘 다 안전하지만 ECC는 동일한 보안 수준으로 더 작은 키와 더 빠른 TLS 핸드셰이크를 제공합니다. 대부분의 현대적 배포에서는 ECC를 사용해야 합니다.
빠른 비교
| ECC (P-256) | RSA 2048 | RSA 4096 | |
|---|---|---|---|
| 키 크기 | 256 bits | 2048 bits | 4096 bits |
| 동등한 보안 수준 | ~128-bit | ~112-bit | ~128-bit |
| TLS 핸드셰이크 속도 | 가장 빠름 | 보통 | 가장 느림 |
| 인증서 크기 | ~500 bytes | ~1,200 bytes | ~2,400 bytes |
| 키 생성 | 빠름 | 보통 | 느림 |
| 브라우저 지원 | 모든 최신 브라우저 | 보편적 | 보편적 |
| Let’s Encrypt 기본값 | ✅ 권장 | 지원됨 | 지원됨 |
| GetHTTPS 기본값 | ✅ P-256 | 선택 가능 | 제공하지 않음 |
대부분의 사용 사례에서 ECC가 더 나은 이유
더 작은 키, 동일한 보안
256비트 ECC 키는 3072비트 RSA 키와 동등한 보안을 제공합니다. 더 작은 키는 다음을 의미합니다:
- 더 작은 인증서 → TLS 핸드셰이크 중 전송 데이터 감소
- 더 빠른 서명 검증 → CPU 부하 감소
- 더 낮은 대역폭 → 트래픽이 많은 사이트와 모바일 연결에서 유리
더 빠른 핸드셰이크
ECDSA 서명 연산은 RSA보다 상당히 빠르며, 특히 서버 측에서 두드러집니다. 트래픽이 많은 사이트의 경우 CPU 사용량과 첫 번째 바이트 수신 시간을 줄여줍니다.
순방향 비밀성
최신 TLS는 인증서 유형에 관계없이 키 교환에 ECDHE(임시 타원 곡선 Diffie-Hellman)를 사용합니다. 하지만 ECC 인증서는 ECDHE와 자연스럽게 조합됩니다 — 전체 핸드셰이크가 타원 곡선 수학을 사용하므로 RSA와 ECDHE를 혼합하는 것보다 더 효율적입니다.
RSA가 여전히 적합한 경우
레거시 기기 호환성
일부 오래된 기기, 임베디드 시스템, IoT 하드웨어는 ECC를 지원하지 않습니다. 다음을 지원해야 하는 경우:
- Windows XP SP2 이하
- 매우 오래된 Android 버전 (< 4.0)
- 특정 임베디드 시스템 또는 하드웨어 로드 밸런서
…RSA 2048이 더 안전한 선택입니다.
조직 요구 사항
일부 컴플라이언스 프레임워크나 내부 정책에서 RSA를 지정할 수 있습니다. 이는 점점 드물어지고 있지만 요구 사항을 확인하세요.
실제 채택 현황
업계는 RSA에서 ECC로 전환하고 있습니다:
| 조직 | 키 유형 | 비고 |
|---|---|---|
| ECDSA P-256 | 모든 Google 서비스 | |
| Cloudflare | ECDSA P-256 | 무료 플랜 인증서의 기본값 |
| Facebook / Meta | ECDSA P-256 | 프로덕션 웹 서버 |
| Let’s Encrypt | ECDSA 권장 | 둘 다 발급, ECC 권장 |
| ZeroSSL | ECDSA 증가 중 | ECC 발급 51.1% 증가(모든 CA 중 가장 빠른 성장) |
사이트에서 사용 중인 알고리즘 확인
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null \
| openssl x509 -noout -text | grep "Public Key Algorithm"
# ECDSA: "id-ecPublicKey"
# RSA: "rsaEncryption"또는 브라우저에서 확인: 자물쇠 아이콘 → 인증서 → 세부 정보 → 주체 공개키 정보.
GetHTTPS의 사용 알고리즘
GetHTTPS는 인증서에 기본적으로 ECDSA P-256 키를 생성하며, ACME 계정 키에도 P-256을 사용합니다. 필요한 경우 인증서 키로 RSA 2048을 선택할 수 있습니다.
P-256(prime256v1 또는 secp256r1이라고도 함)은:
- 모든 최신 브라우저와 서버에서 지원
- Let’s Encrypt 권장
- 대부분의 고트래픽 웹사이트에서 사용(Google, Cloudflare 등)
- Web Crypto API에서 지원(GetHTTPS가 키 생성에 사용)
포스트 양자 고려 사항
ECC와 RSA 모두 양자 컴퓨팅에 안전하지 않습니다. 충분히 강력한 양자 컴퓨터는 Shor 알고리즘을 사용하여 둘 다 해독할 수 있습니다. 업계는 TLS용 포스트 양자 키 교환(ML-KEM, 이전 Kyber)을 하이브리드 모드로 기존 알고리즘과 함께 사용할 수 있도록 개발하고 있습니다.
이것은 현재 인증서 선택에 영향을 미치지 않습니다 — 포스트 양자로의 전환은 인증서 수준이 아닌 프로토콜 수준(TLS)에서 이루어집니다. 지금은 ECC를 사용하고 TLS 스택이 전환을 처리하도록 하세요.
자주 묻는 질문
RSA에서 ECC로(또는 반대로) 전환할 수 있나요?
네. 원하는 키 유형으로 새 인증서를 생성하고 서버의 파일을 교체하면 됩니다. 서버는 이전 인증서가 어떤 알고리즘을 사용했는지 상관하지 않습니다.
웹 서버에 ECC를 위한 특별한 설정이 필요한가요?
아닙니다. Nginx와 Apache는 ECC 인증서를 RSA와 동일한 방식으로 처리합니다 — 동일한 디렉티브, 동일한 파일 형식(PEM). 서버가 키 유형을 자동으로 감지합니다.
P-384가 P-256보다 더 나은가요?
P-384는 P-256의 ~128비트에 비해 ~192비트의 보안을 제공합니다. 실제로 128비트 보안은 현재(또는 예측 가능한 미래에) 해독할 수 있는 수준을 훨씬 초과합니다. P-256이 더 빠르고 더 넓게 최적화되어 있습니다. P-384에 대한 특정 컴플라이언스 요구 사항이 없다면 P-256을 사용하세요.