트리 그림과 발신자 키 그림만 비교하지 말고, 정의된 작업의 비용과 정의된 위협에 대한 근거를 비교하세요.
Messaging Layer Security(MLS)와 Livara의 LGS1은 서로 바꾸어 쓸 수 있는 두 가지 그룹 채팅 안전 인증서가 아닙니다. MLS는 IETF 프로토콜 표준이며, LGS1은 Livara가 문서화한 제품별 설계입니다. 공정하게 비교하려면 구조, 구현 근거, 사용자가 실제로 경험하는 동작을 구분해야 합니다.
핵심 차이는 트리 기반의 공유 그룹 상태와, 두 당사자 간 세션을 통해 배포하는 발신자 키입니다. 어느 이름만으로도 특정 앱이 제거된 멤버, 오래된 상태의 기기, 침해된 키를 올바르게 처리하는지 알 수는 없습니다.
구조의 차이
RFC 9420은 비동기 그룹 키 설정을 위한 MLS를 규정합니다. 래칫 트리와 그룹 에포크를 사용하며 명시된 조건에서 순방향 비밀성과 침해 후 보안을 제공합니다. 트리 구조는 그룹 규모가 커질 때 일부 키 업데이트 비용을 줄입니다.
Livara의 보안 문서는 LGS1을 멤버마다 서명된 발신자 체인을 갖는 방식으로 설명합니다. 이 체인은 LVR1의 두 당사자 간 세션을 통해 배포되며 멤버 구성이 바뀌면 교체됩니다. 이는 제품의 주장이지 LGS1이 MLS를 준수하거나 동일한 분석을 받았다는 근거가 아닙니다.
| 질문 | MLS | Livara LGS1 문서 |
|---|---|---|
| 공유 구조 | 래칫 트리와 에포크 | 발신자별 체인 |
| 키 업데이트 | 그룹 상태 변경을 새 에포크에 커밋 | 새로운 발신자 키를 멤버에게 배포 |
| 명세 지위 | IETF 표준 RFC9420 | 공개된 제품별 설명 |
| 여전히 평가할 부분 | 애플리케이션 통합과 구현 | 완전한 명세, 구현, 독립적인 근거 |
이 표는 설계 범주를 설명합니다. 벤치마크나 보안 순위가 아닙니다.
“로그 규모”가 뜻하는 것과 뜻하지 않는 것
암호학적 업데이트에서 암호화된 트리 경로 구성 요소를 로그 규모의 개수로 사용할 수 있다고 해서 시스템의 모든 작업이 로그 규모가 되는 것은 아닙니다. 메시지는 여전히 배포해야 하고, 클라이언트는 상태를 보관하며, 동작은 그룹 구조와 작업에 따라 달라집니다. “MLS는 O(log N)개의 메시지가 필요하지만 LGS1은 모든 것이 더 빠르다”는 과거 비교는 서로 다른 비용을 섞었고 측정값도 제공하지 않았습니다.
MLS 구조 문서 RFC 9750은 전달 서비스를 암호학적 키 설정과 별도로 다룹니다. 메시지 배포와 그룹 변경 순서도 논의합니다. 이 구분은 중요합니다. 클라이언트 계산, 커밋의 바이트 수, 서버 전체 배포량, 재연결 트래픽은 서로 다른 지표입니다.
의미 있는 성능 보고서는 다음을 명시해야 합니다.
- 그룹 규모와 사람당 기기 수
- 일반 메시지, 멤버 제거, 키 업데이트, 재연결 중 어떤 작업인지
- 시작 클라이언트가 보낸 바이트 수와 전체 전달 트래픽의 구분
- 경과 시간, 기기 모델, 구현 버전, 네트워크 조건
- 놓친 업데이트와 반복되는 멤버 변경의 비용
이런 세부 정보가 없으면 “밀리초”, “낮은 상태 관리 오버헤드”, 특정 그룹 규모에서의 우월성은 입증되지 않은 주장입니다.
멤버 제거는 수명 주기 시험입니다
관리자가 계정을 제거하는 것은 보안 이야기의 일부일 뿐입니다. 클라이언트들은 새 멤버 상태에 합의하고, 적절한 새 키를 사용하며, 제외된 기기에 키를 제공하지 않아야 합니다. 이전 평문이나 키를 이미 보유한 사람은 과거 내용에 계속 접근할 수 있습니다. 제거한다고 그 사람의 사본이 사라지지는 않습니다.
어느 시스템이든 유용한 시험은 다음을 묻습니다. 제거 완료 후 제거된 기기가 민감하지 않은 새로운 테스트 메시지를 복호화할 수 있는가? 오프라인이었던 멤버가 안전하게 최신 상태를 따라잡는가? 계정에 속한 모든 기기가 처리되는가? 인터페이스에 실패나 멤버 변경이 표시되는가?
이는 제안된 평가 질문이지 여기서 수행한 시험 결과가 아닙니다. 제품 비교는 관리자의 클릭 성공을 암호학적 배제와 동일시하기보다 관찰 결과와 시험 버전을 공개해야 합니다.
순방향 비밀성과 복구에는 조건이 있습니다
나중에 키가 침해되어도 이전 메시지를 보호하려면 오래된 비밀 자료를 폐기해야 합니다. 미래 메시지의 보호를 회복하려면 공격자가 관련 접근 권한을 잃은 뒤 새로운 비밀을 반영해야 합니다. MLS에서는 그룹 업데이트를 처리하는 것이 복구의 일부입니다. 업데이트를 보냈다는 사실만으로 모든 멤버가 적용했다는 뜻은 아닙니다. RFC 9420의 보안 고려 사항을 참고하세요.
발신자 키 설계에서는 각 발신자의 침해된 상태를 어떻게 교체하고 재배포하는지 물어보세요. 단방향 체인만으로 현재 상태를 아는 공격자로부터 자동 회복한다고 설명해서는 안 됩니다. 재배포 중 사용하는 두 당사자 간 보호는 중요하지만, 완전한 그룹 수준 분석을 대신하지는 않습니다.
양자 내성 주장에는 구체적인 암호 스위트와 범위가 필요합니다
기본 RFC9420의 암호 스위트는 고전적인 공개 키 메커니즘을 사용합니다. MLS는 확장 가능하므로 특정 구현에 대한 주장은 실제 스위트와 확장을 명시해야 합니다. 모든 MLS 배포가 영구적으로 고전 방식이라고 단정해서는 안 됩니다.
LGS1이 하이브리드 LVR1 배포를 사용한다는 문서의 설명은, 모든 그룹 작업에 대해 독립적으로 분석된 양자 내성 보장과는 다른 주장입니다. FIPS 203은 ML-KEM을 표준화하지만 이를 포함한 전체 그룹 프로토콜을 인증하지는 않습니다. KEM 이름만 보지 말고 인증, 멤버 변경, 키 침해, 구현을 함께 평가하세요.
제품을 결정하기 전에 요청할 것
현재 프로토콜 명세, 테스트 벡터, 미해결 지적 사항을 포함한 릴리스별 독립 검토를 요청하세요. 그런 다음 지원 기기, 업데이트 동작, 복구, 관리 역할, 서버에 보관되는 데이터 같은 일반적인 제품 요건을 비교하세요.
MLS 구조는 애플리케이션 서비스와 그 신뢰 가정을 명시적으로 고려합니다. 마찬가지로 Livara의 위협 모델도 제품 주장과 함께 읽어야 합니다. 암호화는 권한 있는 참여자를 믿을 만하게 만들지 않으며, 스크린샷을 막거나 모든 형태의 메타데이터를 없애지도 않습니다.
근거가 없다면 설계를 자동으로 안전하지 않거나 우월하다고 규정하지 말고 “입증되지 않음”이라고 기록하세요. 결정에는 그룹의 위험과 이용 가능한 근거의 품질이 반영되어야 합니다.
자주 묻는 질문
LGS1은 MLS의 구현인가요?
공개된 설명은 서로 다른 구조를 보여 줍니다. 이 글은 LGS1을 MLS 구현으로 규정하거나 상호 운용성을 주장하지 않습니다.
MLS는 모든 멤버가 동시에 온라인이어야 하나요?
아닙니다. 비동기 사용이 설계에 포함되어 있습니다. 다만 앱에는 지연 업데이트, 오래된 상태, 장기간 오프라인인 멤버에 대한 정책이 필요합니다.
양자 내성 키 배포로 그룹 보안이 해결되나요?
아닙니다. 키 설정의 일부를 다룹니다. 신원, 멤버 구성, 키 수명 주기, 종단점 보안, 구현에는 여전히 근거가 필요합니다.
어떤 설계가 더 빠른가요?
이 글에는 승자를 입증하는 벤치마크가 없습니다. 그룹에 중요한 작업과 배포 환경을 측정하세요.
