결론부터
- 1결론은 직접 만들지 말고 검증된 TDLib 을 쓰는 것.
- 2키를 만들 땐 받은 소수·공개 값·무작위 값을 모두 검사한다.
- 3메시지마다 키·길이·세션·번호·시각 — 하나라도 틀리면 버리고 끊는다.
결론부터 — 직접 만들지 않는다
텔레그램은 MTProto 를 직접 구현하려는 개발자를 위해 '클라이언트 보안 지침'을 공개해 두었습니다. 하지만 이 지침을 읽고 나면 대부분 같은 결론에 닿습니다. 검증된 구현(TDLib)을 쓰는 것이 가장 안전합니다(TDLib 이란). 아래는 직접 구현한다면 무엇을 반드시 확인해야 하는지 항목의 이름과 뜻만 정리한 것입니다. 실제 구현은 공식 지침의 조건을 그대로 따릅니다.
키를 만들 때 확인할 것
| 검사 | 뜻 |
|---|---|
| 받은 소수가 안전한가 | 서버가 준 키 교환용 소수가 정말 '안전한 소수'이고 크기가 맞는지 |
| 생성원·공개 값의 범위 | 너무 작거나 경계에 붙은 값이 아닌지 — 약한 값은 키를 드러낸다 |
| 응답 해시 | 암호화된 응답을 푼 뒤 붙어 온 해시가 내용과 맞는지 |
| 무작위 값 일치 | 이번 교환에서 주고받은 무작위 값들이 처음 것과 같은지 — 다른 교환이 끼어들지 않았는지 |
| 내 비밀 값의 품질 | 내 쪽 비밀 지수를 안전한 난수 생성기로 만들었는지(서버가 준 난수를 그대로 쓰지 않는다) |
이 단계가 무엇을 하는지는 인증 키 만들기에 있습니다.
메시지를 받을 때마다 확인할 것
| 검사 | 뜻 |
|---|---|
| 메시지 키 확인 | 푼 내용으로 다시 계산한 값이 메시지에 붙은 키와 같은지 — 위조·변조 탐지 |
| 길이와 채움 바이트 | 안에 적힌 길이가 실제보다 크지 않은지, 채움 길이가 허용 범위인지 |
| 세션 번호 | 내가 만든 세션의 번호가 맞는지 |
| 메시지 번호 | 보낸 방향에 맞는 짝·홀이 맞는지, 이미 받은 번호를 되풀이하지 않는지 |
| 시각 | 메시지 번호에 담긴 시각이 지금과 너무 멀지 않은지 — 오래된 메시지 재전송 막기 |
직접 구현하기 전 마지막 확인
- 정말 TDLib 으로는 안 되는 이유가 있는가 — 언어·플랫폼 문제라면 tdjson 으로 대부분 해결됩니다(TDLib 빌드).
- 공식 지침과 프로토콜 문서를 처음부터 끝까지 읽고, 위 항목마다 시험을 만들었는가.
- 비밀 대화까지 지원한다면 키 바꾸기와 순서 번호 규칙도 지키는가(비밀 대화 암호화 구조).
- 내 앱이 약관의 개인정보·보안 의무를 지키는가(API 이용 약관).
자주 묻는 질문
텔레그램 MTProto 를 직접 구현해도 되나요?
가능하지만 공식 보안 지침의 모든 검사를 지켜야 하고, 대부분은 검증된 TDLib 을 쓰는 편이 안전합니다.
가장 중요한 검사는 무엇인가요?
키 교환 때 서버가 준 소수와 공개 값이 안전한지 확인하는 것입니다. 이 검사를 빼면 키를 남이 알아낼 수 있습니다.
검사에 실패하면 어떻게 하나요?
그 메시지를 버리고 연결을 닫은 뒤 다시 시도합니다.
메시지 시각은 왜 확인하나요?
오래전 메시지를 다시 보내는 공격을 막기 위해 메시지 번호의 시각이 지금과 너무 멀면 버립니다.
참고한 공식 문서
요약
한눈에 정리
- 1권장
TDLib 먼저.
- 2키 교환
소수 · 범위 · 무작위 값.
- 3메시지
키 · 길이 · 번호 · 시각.
최종 수정 2026-10-06