암호화는 어떤 키가 메시지를 여는지 정합니다. 그 키가 누구에게 전달되었는지는 별도로 확인해야 합니다.
아니요. 그룹 종단 간 암호화만으로는 숨은 구성원을 막지 못합니다. “서버가 그룹 구성원을 추가할 수 있는가?”의 답은 메시지 암호화뿐 아니라 구성원 관리와 확인 방식에 달려 있습니다. Livara 문서에 따르면 실제 E2EE 모드로 동작하는 호환 비공개 그룹에서 LGS1은 콘텐츠를 암호화합니다. 구성원 변경 후 키 교체는 향후 접근을 제한하도록 설계되었으며, 기기에 구성원 정보와 키 업데이트가 적용되어야 합니다. 이미 받은 사본을 회수하지는 못합니다.
핵심 사항
- 종단 간 암호화의 목표는 메시지 기밀성이지만, 구성원 목록의 안전에는 별도 장치가 필요합니다.
- E2EE 상태를 확인한 호환 Livara 비공개 그룹에서 LGS1은 메시지, 수정 내용, 첨부 파일 키를 다룹니다. 호환되지 않는 예전 그룹에 이 주장을 적용하지 마세요.
- Signal, WhatsApp, SimpleX, Element를 “암호화됨” 표시만으로 비교해서는 부족합니다. 구성원 변경 알림, 관리자 역할, 신원 확인 방법도 평가해야 합니다.
- 공격자가 통제하는 허가된 계정의 가입을 인터페이스가 모든 상황에서 탐지할 수는 없습니다. 구성원은 신원과 민감한 변경을 독립적인 경로로 확인해야 합니다.
- Livara Proof Lab은 P-256, HKDF, AES-GCM의 로컬 시연과 파일 해시 확인을 제공합니다. LVR1/LGS1의 완전한 구현이나 독립 감사가 아닙니다.
그룹 암호화가 숨은 구성원을 막을 수 있나요?
아니요. 프로토콜이 콘텐츠뿐 아니라 구성원 상태까지 암호학적으로 검증 가능한 방식으로 구성원 사이에 동기화하지 않는 한 그렇지 않습니다. 이 글에서 “숨은 구성원”은 사람들이 가입을 알아차리지 못했거나 신원을 잘못 파악한 상태에서 향후 메시지에 접근하는 계정입니다.
종단 간 암호화란 대화 당사자들의 기기만 메시지 내용을 읽을 수 있어야 한다는 뜻입니다. 하지만 그 기기들도 누구에게 키를 보내는지 알아야 합니다. 서버가 수신자 목록을 바꿀 수 있다면, 암호화가 정상적으로 작동하면서도 원치 않는 구성원을 위해 메시지가 암호화될 수 있습니다. 콘텐츠와 메타데이터를 구분하려면 “종단 간 암호화와 그 한계” 안내를 참고하세요.
따라서 “암호화된 그룹에 대한 서버 공격”이 반드시 AES를 깨거나 수학 문제를 푸는 것을 뜻하지는 않습니다. 서버는 구성원 관리를 통해 유효한 계정을 향후 수신자에 넣을 수 있습니다. 해당 계정에 키가 없었던 과거 메시지는 별개 문제이며, 주된 위험은 가입 이후의 접근입니다.
Livara 그룹 구성원 관리에 관해 무엇을 알고 있나요?
Livara 보안 문서는 서버의 구성원 및 역할 관리와 콘텐츠 암호화를 구분합니다. 이는 평가에 중요한 경계이지만, 그 사실만으로 성공한 실제 공격이나 완전히 보이지 않는 가입을 입증할 수는 없습니다. 그런 주장을 하려면 클라이언트 동작, 키 배포, 구성원 변경 알림, 공격 조건을 시험해야 합니다.
올바른 질문은 기기가 목록 변경을 독립적으로 검증하는지, 새 구성원에게 키를 보내기 전에 사용자에게 무엇을 보여 주는지입니다. 이 글은 Livara 감사나 침투 테스트 결과를 제시하지 않습니다.
다섯 메신저의 구성원 목록 보안은 어떻게 다른가요?
주요 차이는 누가 구성원 변경을 승인하는지, 구성원들이 어떻게 알게 되는지, 새 계정의 신원을 독립적으로 확인할 수 있는지입니다. 종단 간 암호화가 있다는 사실만으로 메신저 서버에 대한 신뢰를 충분히 설명할 수는 없습니다.
| 메신저 | 그룹 콘텐츠 | 구성원 관리와 실질적 신뢰 | 신중한 결론 |
|---|---|---|---|
| Livara | E2EE가 적용된 호환 비공개 그룹에서 LGS1은 텍스트, 수정 내용, 첨부 파일 키를 다룹니다. | 구성원이 바뀌면 발신자 키가 자동으로 재생성되고 재배포됩니다. | 제품 문서에 따르면 호환 비공개 그룹의 콘텐츠와 미디어 키는 전달 전에 보호됩니다. 해당 그룹의 상태를 확인하세요. |
| Signal | Signal 그룹 지원 문서는 서비스가 그룹 구성원, 제목, 이미지, 속성을 기록하지 않는다고 설명합니다. | 같은 자료에 따르면 관리자는 구성원을 추가할 수 있는 사람을 정하고 그룹 링크에 관리자 승인을 켤 수 있습니다. 구성원들은 여전히 구성원 변경을 확인해야 합니다. | 설계는 서비스가 아는 정보를 제한하지만, 사용자는 구성원 변경과 계정 신원을 확인해야 합니다. |
| WhatsApp 암호화 개요는 개인 및 그룹 메시지가 종단 간 암호화된다고 설명합니다. | WhatsApp 도움말 자료는 새 구성원과 일부 기록을 선택적으로 공유하는 기능과 관리자의 공유 제한 권한을 설명합니다. | 그룹 콘텐츠는 암호화되지만 구성원 자격의 정확성은 관리자 제어와 앱 알림을 통해 평가해야 합니다. | |
| SimpleX | SimpleX 그룹 문서는 각 구성원이 다른 구성원들과 별도의 연결을 가진다고 설명합니다. | 프로토콜 명세는 그룹을 역할과 구성원 변경 메시지가 있는 구성원 간 연결의 집합으로 설명합니다. 이는 사람이 관리자로 존재하는 것과 모순되지 않습니다. | 그룹에 전역 식별자가 없다고 해서 구성원 관리나 감염된 기기의 모든 위험이 없어지는 것은 아닙니다. |
| Element / Matrix | Matrix 종단 간 암호화 명세는 m.room.encryption 이벤트와 방 암호화 알고리즘을 정의합니다. |
Matrix 구성원 명세는 방 상태의 m.room.member 이벤트로 구성원 자격을 모델링하며 홈 서버들이 이를 배포합니다. |
방 암호화와 구성원 상태는 별개의 계층입니다. 구성원은 기기와 방의 변경을 확인해야 합니다. |
이 표는 절대 순위가 아닙니다. 각 시스템은 위협 모델이 다르며 앱, 기기, 그룹 운영, 구성원 행동에 따라 결과가 달라질 수 있습니다. 실제 선택에는 “안전한 메신저 체크리스트의 12가지 질문”을 각 제품의 공식 문서와 함께 사용하세요.
메신저 서버에 대한 신뢰를 어떻게 비교하나요?
신뢰를 단순히 “예” 또는 “아니요”로 줄이지 마세요. 서버가 정확히 무엇을 보고 무엇을 바꿀 수 있는지 물어야 합니다. 본문을 읽지 못하는 서버도 통신 시점, 그룹 구성원, 초기 키 배포를 통제할 수 있습니다.
첫째, 콘텐츠 기밀성을 따로 살펴보세요
메시지, 수정, 반응, 제목, 첨부 파일과 그 키가 정확히 어디서 암호화되는지 확인하세요. Livara 문서에 따르면 LGS1은 E2EE를 사용하는 호환 비공개 그룹의 텍스트, 수정 내용, 첨부 파일 키를 다룹니다. 이 주장은 채널에는 적용되지 않습니다.
둘째, 구성원 관리 권한이 어디에 있는지 확인하세요
누가 초대할 수 있는지, 누가 요청을 승인하는지, 클라이언트가 변경을 어떻게 보여 주는지 파악하세요. 서버가 그룹 상태를 강제한다면 서버 침해 위협을 위협 모델에 명시해야 합니다.
셋째, 신원과 구성원 자격을 구분하세요
익숙한 이름이 있다고 해서 키가 그 사람의 것이라는 증거는 아닙니다. Livara의 safety number는 앱 밖에서 키 지문을 비교할 수 있게 하지만, 이 도구가 있다는 사실만으로 전체 구성원 목록을 확인하는 것은 아닙니다. 키 투명성 기능 역시 문서로 확인될 때만 해당 제품의 기능이라고 말해야 합니다.
넷째, 증거와 주장을 구분하세요
제품 문서, 감사 보고서, 독립 시험은 같지 않습니다. 믿을 만한 보고서는 버전, 점검 범위, 발견 사항, 수정 내용을 명확히 해야 합니다. 알고리즘 이름이나 두 구현의 결과 일치만으로 구성원 관리의 안전성이 입증되지는 않습니다.
그룹 채팅 구성원은 어떻게 확인하나요?
구성원들은 목록 변경을 즉시 확인하고, 민감한 대화에서 중요한 사람들의 신원을 독립적인 채널로 확인해야 합니다. 위험이 큰 대화에서는 이름, 사진, 계정 번호만 봐서는 부족합니다. 이런 단서는 잘못되었거나 재할당되었거나 공격자가 통제할 수 있기 때문입니다.
Livara에서는 두 사람이 직접 만나거나 이미 알고 있는 상대와의 통화 또는 독립적인 경로로 safety number를 비교할 수 있습니다. 예상치 못한 키 변경을 발견할 수 있지만, 두 사람의 비교만으로 큰 그룹의 모든 구성원을 한 번에 확인하는 것은 아닙니다. “safety number로 채팅 확인하기” 안내에 실제 절차가 설명되어 있습니다.
민감한 그룹에는 다음과 같은 짧은 절차가 유용합니다.
- 가능하면 구성원 추가 권한을 관리자로 제한하세요.
- 가입, 탈퇴, 역할 변경 알림을 받을 때마다 즉시 확인하세요.
- 새 구성원의 신원을 그 그룹 밖에서 확인하세요.
- 의심스러운 변경 후에는 민감한 정보 전송을 멈추고 확인된 구성원들과 새 그룹을 만드세요.
- 각 계정의 기기와 연결된 세션을 주기적으로 살펴보세요.
이 조치는 위험을 줄이지만 구성원 관리 아키텍처의 결함을 고치지는 못합니다. 서버나 관리자 계정이 침해되고 인터페이스가 변경을 잘 보여 주지 않으면, 사용자는 여전히 가입을 알아차리지 못할 수 있습니다.
자주 묻는 질문
서버가 암호화를 깨지 않고 그룹 구성원을 추가할 수 있나요?
네. 메신저 아키텍처가 구성원 목록 통제를 서버에 맡긴 경우입니다. 이때 서버는 암호를 깰 필요 없이 향후 수신자에 계정을 추가해 클라이언트가 해당 계정을 위해서도 메시지를 암호화하게 할 수 있습니다. 가능한지와 구체적인 방식은 제품별 구성원 프로토콜에 달려 있습니다.
Livara 그룹에서 LGS1 프로토콜은 어떻게 작동하나요?
제품 문서에 따르면 E2EE를 사용하는 호환 비공개 그룹에서 LGS1은 발신자 키 체인과 서명을 사용해 콘텐츠와 첨부 파일 키를 보호합니다. 구성원이 나간 뒤 향후 접근을 제한하려면 구성원 변경이 적용되고 새 키가 배포되어야 합니다. Proof Lab은 일부 암호 구성 요소의 로컬 시연과 해시 확인만 제공합니다. 이는 완전한 LGS1 구현, 프로토콜 감사, 구성원 관리 안전성의 증명이 아닙니다.
safety number 비교가 숨은 구성원의 가입을 입증하나요?
아니요. safety number 비교는 두 사람 사이에서 키 신원을 독립적인 경로로 확인하며 예상치 못한 키 변경을 발견할 수 있습니다. 하지만 다른 사람이 그룹에 들어오지 않았음을 증명하지는 못합니다. 구성원은 목록, 구성원 알림, 민감한 계정의 신원을 별도로 확인해야 합니다.
어느 메신저의 그룹 구성원 목록이 가장 안전한가요?
이 자료들로 절대적인 승자를 정할 수는 없습니다. Signal, WhatsApp, SimpleX, Element, Livara는 구성원 관리와 위협 모델이 다르기 때문입니다. 올바른 선택은 자신의 위험에 달려 있습니다. 누가 구성원 자격을 통제하는지, 변경을 어떻게 알리는지, 서버 밖에서 구성원의 신원을 확인할 수 있는지 살펴보세요.
