대칭키 암호와 공개키 암호, 무엇이 다를까
암호 이야기에서 가장 먼저 나오는 구분이 대칭키와 공개키입니다. 이름은 어렵지만 생각은 간단합니다. 하나는 문을 잠글 때와 열 때 같은 열쇠를 쓰는 방식이고, 다른 하나는 잠그는 열쇠와 여는 열쇠가 서로 다른 한 쌍인 방식입니다. 둘은 경쟁 관계처럼 보이지만, 실제 서비스에서는 서로의 약점을 메워 주며 함께 쓰이는 경우가 많습니다. 이 글에서는 각각의 원리와 장단점, 그리고 둘을 섞어 쓰는 이유를 살펴봅니다.
대칭키 암호: 같은 열쇠 하나로 잠그고 엽니다
대칭키 암호는 가장 직관적입니다. 친구와 나만 가진 열쇠가 하나 있고, 그 열쇠로 상자를 잠가서 보내면 친구가 같은 열쇠로 엽니다. 고대의 시저 암호부터 오늘날의 AES까지, 암호의 역사 대부분이 이 방식입니다. 장점은 빠르다는 점입니다. 연산이 단순해서 동영상이나 큰 파일, 쏟아지는 메시지도 부담 없이 처리하며, 요즘 프로세서는 AES 전용 명령까지 갖추고 있습니다. 또 같은 안전 수준을 얻는 데 필요한 키가 짧아서 다루기 편합니다.
하지만 대칭키에는 오래된 난제가 있습니다. 그 열쇠를 어떻게 상대에게 안전하게 건네는가입니다. 열쇠를 인터넷으로 보내다가 누군가 엿보면, 그 사람도 모든 대화를 열어 볼 수 있습니다. 만나서 직접 건네면 되지만, 지구 반대편의 낯선 웹사이트와 처음 통신해야 하는 상황에서는 불가능합니다. 또 사람이 늘수록 문제가 커집니다. 10명이 서로 비밀 대화를 하려면 모든 쌍마다 따로 열쇠가 필요해서 열쇠가 45개가 됩니다. 이를 키 배송 문제 또는 키 분배 문제라고 부릅니다.
공개키 암호: 열쇠 한 쌍으로 문제를 풉니다
1970년대에 이 난제를 우회하는 발상이 나왔습니다. 열쇠를 둘로 나누는 것입니다. 공개키는 이름 그대로 누구에게나 알려도 되고, 개인키는 나만 간직합니다. 두 키는 수학적으로 연결되어 있어서, 공개키로 잠근 것은 짝이 되는 개인키로만 열 수 있습니다. 공개키를 가지고는 개인키를 현실적인 시간 안에 계산해 낼 수 없도록 수학 문제의 난이도에 기댑니다.
비유하자면 우체통입니다. 누구나 투입구에 편지를 넣을 수 있지만(공개키로 잠그기), 우체통 안의 편지는 열쇠를 가진 주인만 꺼낼 수 있습니다(개인키로 열기). 열쇠를 미리 몰래 전달할 필요가 없으니 처음 만나는 상대와도 안전한 통신을 시작할 수 있습니다. RSA, 그리고 타원곡선을 쓰는 방식들이 대표적입니다. 같은 원리를 거꾸로 쓰면 디지털 서명이 됩니다. 개인키로 서명하고 공개키로 검증하면, 서명한 사람이 정말 개인키 주인이며 내용이 바뀌지 않았음을 누구나 확인할 수 있습니다.
공개키 방식 중에는 암호문을 직접 만드는 대신, 두 사람이 공개된 값만 주고받으면서 각자 같은 비밀값을 계산해 내는 키 교환 방식도 있습니다. 1976년에 발표된 디피-헬먼 방식이 시초이고, 지금은 타원곡선 기반 변형이 널리 쓰입니다. 도청자가 오가는 값을 전부 봐도 최종 비밀값은 계산할 수 없다는 점이 신기하게 느껴지는 부분입니다.
그럼 공개키만 쓰면 되지 않을까요
공개키가 열쇠 전달 문제를 풀어 주니 대칭키는 필요 없어 보일 수 있습니다. 하지만 공개키 연산은 대칭키보다 훨씬 느리고 계산 비용이 큽니다. 또 한 번에 암호화할 수 있는 데이터의 크기도 제한적입니다. 큰 파일이나 계속 이어지는 대화를 공개키만으로 처리하는 것은 비효율적입니다. 공개키는 "열쇠를 건네는 일"에는 아주 좋지만, "대량의 데이터를 가리는 일"에는 대칭키가 훨씬 잘 맞습니다.
공개키 쪽에도 고유한 어려움이 있습니다. 받은 공개키가 정말 그 상대의 것인지 어떻게 아느냐는 문제입니다. 중간에 누군가 자기 공개키를 상대 것인 양 바꿔치기하면, 나는 공격자에게 암호화해서 보내게 됩니다. 이를 중간자 공격이라 부릅니다. 웹에서는 인증기관이 "이 공개키는 이 사이트의 것"이라고 보증하는 인증서 체계로 이 문제를 다루고, 메신저들은 상대의 키 지문(안전 번호 같은 것)을 직접 만나거나 다른 수단으로 대조해 보게 합니다.
실제 서비스는 둘을 섞어 씁니다
그래서 현실의 서비스는 하이브리드 방식을 씁니다. 웹사이트에 접속할 때 쓰는 HTTPS(TLS)를 예로 들면 흐름은 대략 이렇습니다. 처음에는 공개키 방식(서버 인증서와 키 교환)으로 상대가 진짜인지 확인하면서 둘만 아는 비밀값을 만듭니다. 그 비밀값에서 대칭키를 뽑아냅니다. 이후 실제 페이지와 데이터는 그 대칭키로 빠르게 암호화합니다. 공개키는 "악수"를 맡고, 대칭키는 "대화"를 맡는 것입니다. 이메일 암호화 도구나 최신 메신저들도 구체적인 방식은 다르지만 같은 역할 분담을 합니다.
비유하면 두 사람이 비밀 대화를 하기 위해 먼저 우체통 방식(공개키)으로 "오늘 대화에 쓸 임시 열쇠"를 안전하게 주고받고, 그다음부터는 그 열쇠로 튼튼한 금고 상자(대칭키)에 담아 빠르게 주고받는 모양입니다. 임시 열쇠는 대화마다 새로 만들면 나중에 하나가 유출되어도 다른 대화는 안전하게 남는 장점도 생깁니다.
이 서비스는 어디에 속할까요
이 서비스의 번역기는 대칭키 방식입니다. 글을 AES-GCM으로 암호화하고, 해독에 필요한 키 재료는 번역기 주소의 # 뒤에 들어 있습니다. 즉 주소가 곧 열쇠이며, 친구에게 그 주소를 건네는 순간이 앞서 말한 "열쇠 배송"입니다. 이 서비스는 그 문제를 푸는 대신 사람에게 맡깁니다. 주소를 직접 만나서 전달하거나, 이미 신뢰하는 통로로 한 번만 보내라는 뜻입니다. 이 주소가 담긴 대화창이 도청되거나 계정이 탈취되면 그 번역기의 비밀어는 모두 열릴 수 있습니다. 다만 비밀번호를 걸어 두면 주소만으로는 풀 수 없고 비밀번호도 필요하므로, 주소와 비밀번호를 서로 다른 경로로 전하면 위험을 나눌 수 있습니다.
이 방식의 장점은 구조가 단순해서 이해하기 쉽고, 각자 개인키를 관리하거나 앱을 설치할 필요가 없다는 것입니다. 단점은 공개키 방식의 메신저와 달리 대화마다 새 열쇠를 자동으로 바꿔 주지 않으며, 주소 하나가 곧 비밀의 전부라는 점입니다. 어떤 방식이 낫다기보다 용도가 다릅니다. 일상의 가벼운 비밀을 기존 메신저 위에서 가리고 싶을 때와, 전문 메신저로 장기 대화를 안전하게 이어 갈 때는 요구 조건이 다르기 때문입니다.
기억해 둘 요점
- 대칭키는 빠르고 단순하지만 열쇠를 안전하게 전달해야 합니다.
- 공개키는 열쇠 전달 문제를 풀어 주지만 느리고, 상대의 공개키가 진짜인지 확인해야 합니다.
- 실제 서비스는 공개키로 대칭키를 합의하고, 대화는 대칭키로 처리하는 하이브리드 구조를 흔히 씁니다.
이 구분 위에서 "누가 열쇠를 가지고 있는가"를 따지는 개념이 종단간 암호화입니다. 이어서 종단간 암호화(E2EE)란?을 읽어 보시면 오늘 다룬 개념이 메신저에서 어떻게 적용되고 어디까지 보호하는지 더 분명해집니다.
잘못된 내용이나 보완할 점을 발견하셨다면 소개·문의의 이메일로 알려 주세요. 확인 후 글을 고치고 수정일을 갱신합니다.