▲

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

 (mjg59.dreamwidth.org)
1P by GN⁺ 21시간전 | ★ favorite | 댓글 1개
  • 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과 같은 공개적이고 투명한 프로토콜의 메신저 사용을 강력 추천
▲
GN⁺ 21시간전  [-]
Hacker News 의견

  • 나는 Matthew Garrett가 쓴 모든 글을 좋아하는 팬이지만, Signal이 예전부터 항상 forward secrecy 기능을 지원해온 점을 집착스럽게 지적하고 싶음. 현대의 안전한 메신저 개념은 OTR(Borisov와 Goldberg)이 거의 처음으로 "완벽한 forward secrecy"와 부인 가능성에 대한 개념을 도입하면서 탄생. Signal은 이 아이디어와, 그러한 아이디어의 엔지니어링 측면(더 나은 암호화, 더 나은 코드, 더 나은 패키징)을 모두 발전시킨 결과물이란 생각. 답답한 점은 새로운 메신저들이 "pre-Signal" 수준이 아니라 2001년 이전, 즉 현대 이전의 보안 수준으로 후퇴하고 있다는 사실임

    • 과거 여러 유출 내용에서 기억해야 할 세 가지가 있음. (1) FBI가 기업들에게 비밀리에 백도어를 넣으라고 "강제"한 사실이 있음. FISA 법원이 회사에 치명적인 벌금을 내릴 수 있다는 언급도 나왔음. (2) 대기업에게 백도어 비용으로 수천만~억 단위 금액을 지급함. 그리고 정부 계약 혹은 수출 라이센스 등 다양한 방법으로 압박함. 결국 "은행 아니면 총" 식 정책이란 해석 가능. (3) Lavabit 재판 사례에서는 FBI가 키 제공을 요구하면서도, 고객에게 거짓말하라고 사실상 강요함. 이런 사례를 떠올리면 대형 플랫폼 내 암호화가 정부의 요구로 일부러 약화되거나, 그냥 신경을 안 써서 허술하게 적용된 경우가 꽤 잦을 거란 의심이 듦. Patriot Act, FISC, 비밀 해석 등 관련 법령과 관행이 없어지고 위반자들이 처벌받기 전까지, 경찰국가 내 암호화는 Five Eyes에 의해 이미 무너졌단 가정임

    • 사람들이 App Store에서 PC 기반 앱을 설치하는 한, 이런 후진적인 상황은 계속될 전망

  • 만약 ephemeral key를 사용하고 forward secrecy나 상호작용 기록도 없다면, 어떤 점이 진짜 'bitcoin 스타일'이란 건지 의문임

    • 암호기술이 쓰였긴 한데, 대체로 흥미없고 무쓸모에 가까운 파생 기술 느낌

    • 실질적인 활용 가치가 없다는 얘기임

    • Bitcoin 자체도 안전한 통신 채널은 아니라는 사실

    • PIN 기반 키 파생을 쓴다는 점이 있음. 근데 이는 메시징 자체보다는 백업 구현에 더 가까운 방식으로, 본질적 특징이라 보기도 어려움

    • 해시 함수를 사용한다는 점 언급

  • 예전 토론 링크 공유:
    X의 새로운 "암호화된" XChat도 그다지 더 안전하진 않다

    • 위 링크의 상위 댓글에서 기술적으로 깊이 다루는데, 결론은 이렇게 요약 가능: "도움말 문서에도 명시됐지만 forward secure하지 않아서, 키만 있으면 전부 복호화됨. e2ee 플랫폼이라 부를 수 없는 수준."
      관련 댓글 보기

  • 암호화하려면 별도의 소프트웨어를 이용하고, 공개키는 직접 대면해서 교환하는 방식이 더 낫겠다는 생각

  • 질문: 곧 베이징에 방문할 예정인데, VPN 없이 Twitter 사용이 가능한지 궁금

    • 일부 로밍 SIM 카드는 만리방화벽에 적용되지 않는 경우도 있으나, 대부분의 경우 VPN 필요

  • "Bitcoin style encryption"이라는 표현을 두고 의문. 실제로 Bitcoin은 우리가 흔히 아는 "encryption"이 아니라 암호 서명 기술에 더 의존한다고 인식함

    • 이 용어는 실제론 아무 의미 없고, 기술에 익숙하지 않은 사람에게 그럴듯하게 들리라고 쓴 마케팅 용어일 뿐

    • 해당 발언의 출처 자체가 기술적으로 깊은 사람은 아니란 점을 유념해야 함

    • 이 용어를 쓴 건 이슈를 불러일으킬 걸 예상했기 때문임. 더 주목받기 위한 전략적 선택이라는 해석

    • 설명 영상 링크 공유
      https://www.youtube.com/watch?v=sJNK4VKeoBM

    • 그냥 멋져 보이게 “가치있는 것”처럼 느끼게 하려고 쓴 유행어 수준의 단어

  • 진짜 XChat(IRC 클라이언트)이 X-Twitter를 상표권 침해로 고소할 수 있을지 의문
    http://xchat.org/

    • 예전에 XChat에서 HexChat으로 넘어가던 시절 IRC 이용자였던 추억이 있음. 그런데 HexChat도 개발 종료 소식에 놀람
      HexChat 종료 소식

    • 아마 가능은 한데, XChat 쪽이 X가 침해하는 영역마다 상업적 시장성을 잘 입증해야 하고, 각 지역에서 상표권이 등록돼 있어야 쉽게 인정 가능. 그게 아니면 더 어렵다는 의견

  • Twitter가 사용하는 라이브러리(출처 기사 기준)가 재밌는 점이, 개발자 본인이 라이브러리 설명에
    “경고: 실험용 라이브러리! 이건 검토 전까진 프로덕션에 쓰지 마세요. 리스크 및 버그 가능성 큼”
    이라고 직접 써놓았다는 사실
    https://github.com/ionspin/kotlin-multiplatform-libsodium

    • 파괴적 혁신 대신 파괴적 암호화라는 생각

  • Twitter 브랜드 파워가 워낙 강해서 리브랜딩 이후에도 여전히 생명력을 잃지 않는다는 감탄

    • 각주에서 저자가 왜 예전 명칭을 썼는지 자세히 설명함
답변달기