대칭키 vs 비대칭키 - 왜 둘 중 하나만 쓰지 않을까

암호화 요건 회의에서 자주 나오는 질문이 있습니다. "공개키 암호가 더 안전하다던데, 그냥 RSA로 전부 암호화하면 안 되나요?" 반대로 "AES 하나면 충분한데 인증서는 왜 필요하냐"는 질문도 나옵니다. 둘 다 그럴듯하지만, 실제로 해 보면 RSA는 1MB 파일 하나도 한 번에 못 담고, AES는 키를 상대에게 건네는 순간부터 막힙니다. 그래서 TLS, 이메일 암호화, 파일 암호화 도구는 거의 예외 없이 둘을 섞어 씁니다. 결론부터 말하면 둘은 경쟁 관계가 아니라 서로의 약점을 메우는 짝이고, 그 이유는 OpenSSL 명령 몇 줄이면 숫자로 확인할 수 있습니다.

키 하나 vs 키 한 쌍, 무엇이 다른가 (개념)

대칭키는 잠그는 열쇠와 여는 열쇠가 같습니다. 집 열쇠를 복사해 가족에게 나눠 주는 방식이에요. 비대칭키는 공개키와 개인키 한 쌍입니다. 공개키는 누구나 넣을 수 있는 우체통 투입구이고, 개인키는 우체통을 여는 열쇠라서 주인만 갖습니다.

구분	대칭키	비대칭키
키	하나를 양쪽이 공유	공개키·개인키 한 쌍
대표 알고리즘	AES, ChaCha20	RSA, ECDSA, ECDH
속도	빠름, 대용량 데이터용	느림, 짧은 데이터용
약점	키를 어떻게 안전하게 전달하나	느리고 한 번에 담는 크기가 작음
주 용도	데이터 암호화, MAC	키 전달·합의, 전자서명

NIST SP 800-175B Rev. 1도 같은 구분을 합니다. 비대칭 알고리즘은 대칭 알고리즘보다 훨씬 느려서 대량 데이터 처리에는 쓰지 않고, 전자서명과 키 수립(키 전달·키 합의)에 쓴다고 설명합니다. 그리고 둘을 섞는 방식이 비대칭만 쓸 때보다 효율적이고, 대칭만 쓸 때보다 필요한 키 수가 줄어든다고 정리합니다.

키 수 차이는 생각보다 큽니다. n명이 서로 1:1로 비밀 통신하려면 대칭키는 n(n-1)/2개가 필요하지만, 비대칭키는 사람마다 한 쌍이면 됩니다. 1,000명이면 대칭키 499,500개 대 키 쌍 1,000개입니다.

같은 보안 강도를 내는 데 필요한 키 길이도 다릅니다. NIST SP 800-57 Part 1 Rev. 5 표 2 기준입니다.

보안 강도	대칭키	RSA	ECC
128비트	AES-128	3072비트	256~383비트
192비트	AES-192	7680비트	384~511비트
256비트	AES-256	15360비트	512비트 이상

OpenSSL로 속도·크기 한계와 하이브리드 확인 (실전 예제)

실행 환경: Ubuntu 24.04 / OpenSSL 3.0.13, 2코어 클라우드 VM. 속도 수치는 장비마다 크게 다르니 비율만 보세요.

1) 속도 재 보기.

openssl speed -seconds 3 -evp aes-256-gcm
openssl speed -seconds 3 rsa3072

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
AES-256-GCM     704420.46k  2687698.62k  5508236.03k  8117442.22k 11346985.78k 11721015.30k
                  sign    verify    sign/s verify/s
rsa 3072 bits 0.001020s 0.000044s    980.7  22809.3

AES-256-GCM은 16KB 블록에서 초당 약 11.7GB를 처리했습니다. RSA-3072은 한 번에 최대 318바이트만 담으므로(2번 참고) 연산 횟수에 곱해 환산하면, 공개키 연산(암호화, 초당 22,809회)은 약 7.3MB/s로 AES보다 약 1,600배, 개인키 연산(복호화, 초당 980회)은 약 0.3MB/s로 약 3.7만 배 느립니다. 2코어 VM에서 한 번 잰 값입니다.

2) RSA로 큰 데이터를 직접 암호화해 보기. RSA-3072 키에 OAEP(SHA-256) 패딩을 쓰면 RFC 8017의 공식 k - 2hLen - 2에 따라 384 - 64 - 2 = 318바이트가 한계입니다.

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out bob.key
openssl pkey -in bob.key -pubout -out bob.pub
OAEP="-pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256"
head -c 318 /dev/urandom > m318; head -c 319 /dev/urandom > m319
openssl pkeyutl -encrypt -pubin -inkey bob.pub $OAEP -in m318 -out m318.rsa   # 성공
openssl pkeyutl -encrypt -pubin -inkey bob.pub $OAEP -in m319 -out m319.rsa   # 실패

318바이트는 384바이트 암호문이 됐고, 319바이트와 1MB 파일은 data too large for key size로 실패했습니다.

3) 하이브리드 암호화. 데이터는 랜덤 AES 키로, 그 AES 키만 RSA 공개키로 감쌉니다.

head -c 1048576 /dev/urandom > report.bin
# 보내는 쪽
openssl rand -hex 32 > aes.key
openssl enc -aes-256-cbc -pbkdf2 -salt -pass file:aes.key -in report.bin -out report.enc
openssl pkeyutl -encrypt -pubin -inkey bob.pub $OAEP -in aes.key -out aes.key.wrapped
# 받는 쪽
openssl pkeyutl -decrypt -inkey bob.key $OAEP -in aes.key.wrapped -out aes.key.bob
openssl enc -d -aes-256-cbc -pbkdf2 -pass file:aes.key.bob -in report.enc -out report.dec
sha256sum report.bin report.dec

aes.key는 랜덤 16진수 64자리이고, enc가 이 값을 PBKDF2에 넣어 실제 AES 키를 만듭니다. 1MB 파일은 AES가 처리하고, RSA는 65바이트짜리 키 파일만 384바이트로 감쌌습니다. 복호화한 파일의 SHA-256은 원본과 같았습니다(0e2ebab4…).

4) 비대칭키만 할 수 있는 일, 서명. 대칭키 기반 MAC은 키를 가진 양쪽 누구나 만들 수 있어서 "누가 만들었는지"를 제3자에게 증명하지 못합니다. 서명은 개인키 주인만 만들 수 있습니다.

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out alice.key
openssl pkey -in alice.key -pubout -out alice.pub
printf 'transfer 100 to bob\n' > order.txt
openssl dgst -sha256 -sign alice.key -out order.sig order.txt
openssl dgst -sha256 -verify alice.pub -signature order.sig order.txt

원본은 Verified OK, 금액을 900으로 바꾸자 Verification failure가 나왔습니다.

섞어 쓸 때 흔한 실수 (주의할 점)

• RSA로 데이터를 잘라서 직접 암호화하기. 크기 한계를 피하려고 데이터를 318바이트씩 잘라 RSA로 돌리는 코드가 있는데, 느리고 표준 방식도 아닙니다. 데이터는 대칭키로 처리합니다.
• OAEP 해시 기본값 확인. OpenSSL 3.0 pkeyutl 매뉴얼에 따르면 rsa_oaep_md를 지정하지 않으면 SHA-1을 씁니다. 상대 시스템과 해시를 맞추지 않으면 복호화가 실패합니다.
• openssl enc는 무결성을 보장하지 않는다. 매뉴얼에 GCM 같은 인증 암호화 모드를 지원하지 않는다고 명시돼 있습니다. 위 실습은 원리 확인용이고, 실제 서비스는 AES-GCM을 지원하는 라이브러리나 CMS·TLS 같은 표준 형식을 씁니다.
• 키 길이를 같은 숫자로 비교하지 않기. RSA-2048은 NIST 표 2에서 112비트 강도로 AES-128보다 낮습니다. 128비트 강도가 목표면 RSA-3072 또는 P-256입니다.
• 양자 컴퓨터 이슈는 비대칭 쪽에 몰려 있다. NIST IR 8547 초안(2024년 11월)은 RSA와 ECDSA가 충분히 큰 양자 컴퓨터의 쇼어 알고리즘에 취약하고, 대칭 알고리즘은 영향이 훨씬 적다고 봅니다. 2024년 8월 나온 FIPS 203(ML-KEM)도 공유 키를 수립한 뒤 데이터는 대칭 알고리즘으로 처리하는 구조라, 하이브리드에서 바뀌는 쪽은 주로 키 전달 부분입니다.

두 방식의 역할 분담 (마무리)

한 문장씩만 남기면 이렇습니다.

• 대칭키는 데이터를, 비대칭키는 그 대칭키 전달과 서명을 맡는다.
• RSA는 한 번에 담는 크기가 키 길이로 정해져 있어 대용량 암호화에 쓸 수 없다.
• 키 길이는 보안 강도로 비교하고, 패딩·해시 설정은 양쪽이 같아야 한다.

원문과 표준 문서 (참고 자료)

• NIST SP 800-175B Rev. 1, Guideline for Using Cryptographic Standards: Cryptographic Mechanisms: https://csrc.nist.gov/pubs/sp/800/175/b/r1/final
• NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management (표 2): https://doi.org/10.6028/NIST.SP.800-57pt1r5
• RFC 8017, PKCS #1: RSA Cryptography Specifications v2.2: https://datatracker.ietf.org/doc/html/rfc8017
• NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard: https://csrc.nist.gov/pubs/fips/203/final
• NIST IR 8547 (초안), Transition to Post-Quantum Cryptography Standards: https://csrc.nist.gov/pubs/ir/8547/ipd
• OpenSSL 3.0 매뉴얼 — openssl-pkeyutl: https://docs.openssl.org/3.0/man1/openssl-pkeyutl/
• OpenSSL 3.0 매뉴얼 — openssl-enc: https://docs.openssl.org/3.0/man1/openssl-enc/
• OpenSSL 3.0 매뉴얼 — openssl-speed: https://docs.openssl.org/3.0/man1/openssl-speed/