트위터의 새로운 암호화 DM은 이전 것보다 더 낫지 않음

• Twitter(X)의 새 암호화 DM(XChat) 은 기술적으로 end-to-end 암호화를 표방하지만, 프라이빗 키 탈취·MITM·메타데이터 노출 등 심각한 보안 결함이 여전히 존재함
• Libsodium Box(비밀키 기반 암호화) 를 도입했으나, forward secrecy 미지원과 4자리 PIN 기반 약한 키 보호 방식으로 프라이빗 키 추출이 비교적 용이함
• Juicebox 프로토콜로 키를 백업/복구하나, 실제 보안성은 백엔드 신뢰에 전적으로 의존하고, Twitter가 모든 백엔드를 직접 운영해 sharding의 의미가 거의 없음
• 공개키 인증/검증을 위한 out-of-band 절차가 없어 Twitter가 MITM(중간자 공격)으로 키를 바꿔치기할 수 있으며, 사용자 메타데이터는 그대로 노출됨
• Signal과 달리, 현재로선 실질적 프라이버시 보호가 부족하므로 신뢰할 수 있는 암호화 메신저로 Signal을 추천함

Twitter의 새로운 암호화 DM 분석

배경 및 요약

• Twitter(X)는 새로운 XChat 암호화 메시지 플랫폼을 공개, Rust로 개발됐고 Bitcoin 스타일의 암호화 구조를 도입했다고 홍보
• 하지만 실제 구현을 보면, 여전히 Twitter가 프라이빗 키 접근, MITM(중간자 공격), 메타데이터 수집이 가능한 구조임
• 결론: Signal을 사용 권장, Twitter(X) DM은 근본적인 한계로 안전하지 않음

암호화 구조 및 한계

1. 암호화 방식

• Libsodium의 box(공개키 기반 암호화) 를 사용
• forward secrecy(선행 비밀성) 미지원: 프라이빗 키가 유출되면 기존 메시지 모두 복호화 가능(즉, Signal 등 최신 메신저보다 취약)
• 실제 구현은 Rust가 아니라 C 라이브러리(jni로 바인딩)를 사용

2. 키 저장 및 복구(Juicebox 프로토콜)

• 기기에서 생성된 프라이빗 키를 Juicebox 프로토콜로 저장
• 키는 PIN(4자리) 기반 암호화 후 저장되며, 복구 시 PIN 입력 필요
• 서버는 PIN을 모르지만, PIN이 4자리(1만개 경우의 수)에 불과해 병렬 브루트포스로 빠르게 크랙 가능
• Argon2id로 16MB 메모리·32회 반복을 적용해도 실제 공격자에겐 큰 장애가 아님(저사양 노트북에서도 0.2초 이내)

3. 키 분산(Sharding) 구조 한계

• Juicebox는 다중 백엔드 분산(sharding) 지원하지만, Twitter는 3개의 백엔드를 모두 직접 운영
• 결국 키 복구 과정에서 Twitter의 신뢰에 완전히 의존해야 하며, sharding의 근본적 보안 이점이 없음
• 백엔드와 안전하게 통신하는 HSM, SGX 등 하드웨어 검증 절차도 부재

4. 공개키 인증/교환 취약점

• 상대방의 공개키는 Twitter 서버를 통해 받기만 하고, 별도 검증(out-of-band) 수단 없음
• Twitter가 원하는 때에 임의의 공개키를 제공해 중간자 공격(MITM) 가능
• 공식 지원 페이지에서도 해당 취약점을 인정하며, 향후 개선 예고만 했으나 실질적 조치 없음

5. 메타데이터 및 기타 문제

• 누가 누구에게, 언제 메시지를 주고받는지 등 메타데이터는 Twitter가 완전히 파악 가능
• 프라이빗 키가 노출되지 않아도 사용자의 커뮤니케이션 패턴은 여전히 회사에 노출됨

결론 및 권고

• 암호화 DM의 설계상 한계로, 실제 보안과 프라이버시 측면에서 Signal 등 검증된 메신저에 미치지 못함
• Twitter가 공개키·키스토어·통신 경로 모두를 통제하는 한 진정한 end-to-end 암호화로 볼 수 없음
• Signal과 같은 공개적이고 투명한 프로토콜의 메신저 사용을 강력 추천