결론부터
- 1인증 키는 오가지 않는다 — 양쪽이 디피-헬먼 교환으로 각자 계산한다.
- 2앱에 든 서버 공개 키로 진짜 서버인지 확인한다.
- 3받은 소수·공개 값 검사를 빼면 암호화 전체가 무너진다.
인증 키란
텔레그램 앱이 서버와 주고받는 모든 메시지는 인증 키(auth key)로 암호화됩니다. 앱을 처음 켜서 데이터 센터에 처음 연결할 때 서버와 함께 만들고, 그 뒤로는 거의 바꾸지 않습니다. 이 키는 네트워크로 한 번도 오가지 않습니다 — 양쪽이 각자 계산해서 같은 값을 얻는 디피-헬먼 키 교환(2048비트)으로 만듭니다.
TDLib 이나 공식 앱은 이 과정을 알아서 합니다. 이 글은 '무슨 일이 일어나는지'를 이해하기 위한 개념 설명입니다. 직접 구현한다면 공식 문서의 단계와 검사를 그대로 따라야 합니다(보안 지침).
다섯 단계로 보기
| 단계 | 무슨 일 | 왜 |
|---|---|---|
| 1. 인사 | 앱이 무작위 값(nonce)을 보내고, 서버가 자기 무작위 값과 '풀어 볼 숫자 문제', 자기 RSA 공개 키 지문을 돌려준다 | 이번 교환을 다른 교환과 섞이지 않게 묶는다 |
| 2. 서버 확인 | 앱이 숫자 문제(큰 수를 두 소수로 나누기)를 풀어, 새 무작위 값과 함께 서버의 공개 키로 암호화해 보낸다 | 앱에 미리 들어 있는 공개 키의 짝(비밀 키)을 가진 진짜 서버만 읽을 수 있다 · 문제 풀이는 가벼운 작업 증명 |
| 3. 재료 받기 | 서버가 키 교환에 쓸 수(큰 소수와 생성원, 서버 쪽 공개 값)를 암호화해 보낸다 | 키를 만들 공통 재료 |
| 4. 검사와 내 값 보내기 | 앱이 받은 수가 안전한지 반드시 검사한 뒤, 자기 쪽 공개 값을 보낸다 | 약한 수를 받아들이면 키를 남이 계산할 수 있다 |
| 5. 같은 키, 확인 | 양쪽이 각자 같은 인증 키를 계산하고, 서버가 '성공·다시·실패'로 확인해 준다 | 키 자체는 오가지 않는다 |
마지막에 교환에 쓴 값들로 첫 서버 소금(server salt)도 정해집니다. 소금은 이후 메시지 암호화에 섞이는 값으로, 서버가 주기적으로 새 값을 알려 줍니다.
데이터 센터마다, 그리고 임시 키
- 인증 키는 데이터 센터마다 따로 만듭니다(데이터 센터).
- 오래 쓰는 기본 키 위에 임시 키를 따로 만들어 묶어 쓰면, 기본 키가 나중에 새더라도 지난 대화가 풀리지 않게 할 수 있습니다(완전 순방향 비밀성). 공식 앱은 이 방식을 씁니다.
- 인증 키가 들어 있는 세션 파일은 계정 그 자체입니다. 기기 밖으로 내보내지 않습니다(MTProto 한눈에).
자주 묻는 질문
텔레그램 인증 키는 언제 만들어지나요?
앱이 데이터 센터에 처음 연결할 때 서버와 함께 만들고, 그 뒤로는 거의 바꾸지 않습니다.
인증 키가 네트워크로 전송되나요?
아닙니다. 디피-헬먼 교환으로 앱과 서버가 각자 같은 값을 계산합니다.
가짜 서버와 키를 만들 수는 없나요?
앱에 미리 들어 있는 서버 공개 키로 암호화한 값을 진짜 서버만 읽을 수 있어 막힙니다. 받은 수의 검사도 함께 해야 합니다.
직접 구현해야 하나요?
대부분은 아닙니다. TDLib 이나 공식 앱이 이 과정을 대신 합니다.
참고한 공식 문서
요약
한눈에 정리
- 1교환
디피-헬먼 · 키는 안 오감.
- 2확인
서버 RSA 공개 키.
- 3검사
받은 수가 안전한지.
최종 수정 2026-10-06
