안전한 메시지 앱 선택법: 근거를 확인하는 12가지 질문

메시지 앱에 자물쇠가 표시되고 프라이버시를 지킨다고 홍보하더라도, 중요한 질문에는 답하지 않을 수 있습니다.

어떤 대화가 암호화되나요? 첨부파일도 보호되나요? 키는 어디에 저장되나요? 서버는 어떤 정보를 보관하나요? 기기를 잃어버리면 어떻게 되나요? 암호화 키가 경고 없이 바뀔 수 있나요?

이러한 세부 사항은 유용한 보호 기능과 아직 부족한 증거를 함께 파악하는 데 도움이 됩니다. 어떤 점검표도 그 자체만으로 제품의 안전성을 인증하지는 못합니다.

이 안내서는 개인 대화, 기밀 파일, 민감한 업무를 암호화 메시지 앱에 맡기기 전에 물어야 할 실용적인 질문 12가지를 제공합니다.

안전한 메시지 앱이란 무엇인가요?

안전한 메시지 앱은 무단 접근, 도청, 계정 침해, 의도하지 않은 데이터 노출로부터 대화를 보호하도록 설계된 통신 서비스입니다.

프라이버시를 진지하게 다루는 메시지 앱이라면 최소한 안전한 네트워크 전송, 강력한 계정 인증, 신중한 접근 제어, 명확한 데이터 처리 방식을 갖춰야 합니다.

높은 수준의 비공개성이 필요한 대화에는 종단간 암호화도 제공해야 합니다.

종단간 암호화, 즉 E2EE는 지원되는 내용을 발신자의 기기에서 암호화하고 허가된 수신자의 기기에서 복호화해 보호합니다. 서비스는 읽을 수 있는 메시지 본문 없이도 암호화된 데이터를 전달할 수 있습니다.

그러나 암호화는 메시지 보안의 한 부분일 뿐입니다.

완전한 평가에는 다음 사항도 포함해야 합니다.

• 어떤 대화가 암호화되는지
• 사진과 파일에도 같은 보호가 적용되는지
• 개인 키가 어디에 저장되는지
• 연락처끼리 키를 어떻게 검증하는지
• 어떤 메타데이터가 여전히 보이는지
• 계정 및 키 복구가 어떻게 작동하는지
• 기기가 침해되면 어떻게 되는지
• 서비스가 한계를 어떻게 문서화하는지

더 자세한 입문 설명은 ‘종단간 암호화 설명’을 읽어 보세요.

‘암호화’라는 말만으로 충분하지 않은 이유

거의 모든 현대적인 메시지 서비스는 HTTPS, TLS 또는 다른 보호된 전송 방식으로 네트워크 트래픽을 암호화합니다.

이 보호는 중요하지만, 대화가 반드시 종단간 암호화된다는 뜻은 아닙니다.

전송 암호화는 기기와 서비스 사이를 이동하는 데이터를 보호합니다. 서비스는 읽을 수 있는 내용을 받은 뒤 다른 보호된 연결로 전달할 수도 있습니다.

E2EE에서는 지원되는 메시지 내용이 메시지 서비스에 도달하기 전에 참여자를 대상으로 암호화됩니다.

이 차이는 기술적으로 누가 메시지 본문에 접근할 수 있는지에 영향을 줍니다.

따라서 일반적인 ‘암호화됨’ 표시를 받아들이기보다 정확한 질문을 해야 합니다.

주장	물어야 할 질문
‘채팅이 암호화됩니다’	전송 중에만 암호화되나요, 아니면 종단간 암호화인가요?
‘데이터가 안전합니다’	어떤 데이터를 어떤 위협으로부터 얼마나 오래 보호하나요?
‘저희는 메시지를 읽을 수 없습니다’	개인 채팅, 그룹, 미디어, 통화, 백업까지 포함하나요?
‘설계부터 프라이버시를 고려합니다’	어떤 메타데이터와 운영 정보가 계속 이용 가능한가요?
‘안전한 복구를 제공합니다’	누가 암호화 키를 복원할 수 있으며 어떤 비밀 정보가 필요한가요?

1. 어떤 대화가 종단간 암호화되나요?

하나의 암호화 설명이 앱의 모든 부분에 적용된다고 가정하지 마세요.

메시지 서비스는 다음 영역에 서로 다른 보호를 제공할 수 있습니다.

• 일대일 개인 대화
• 비공개 그룹
• 공개 그룹
• 방송 채널
• 음성 및 영상 통화
• 스토리 또는 임시 게시물
• 봇과 자동화 계정
• 동기화되는 대화 기록

제공업체에 정확한 경계를 밝혀 달라고 요청하세요.

구체적인 답변은 다음과 같습니다.

개인 메시지 본문과 미디어는 참여자의 기기에서 암호화됩니다. 호환되는 비공개 그룹은 LGS1으로 종단간 암호화되며, 구성원이 바뀌면 발신자 키가 자동으로 교체됩니다. 채널은 서버가 읽을 수 있는 별도 구조를 사용하며 E2EE라고 설명하지 않습니다.

부실한 답변은 다음과 같습니다.

여러분의 통신은 군용 등급 암호화로 보호됩니다.

첫 번째 답변은 평가할 수 있는 정보를 제공합니다. 두 번째는 보호되는 내용이나 위협 모델을 정의하지 않은 채 인상적인 표현만 사용합니다.

2. 사진, 동영상, 첨부파일도 암호화되나요?

앱이 텍스트는 암호화하면서 업로드된 미디어는 다른 시스템으로 처리할 수 있습니다.

그러면 중요한 질문이 생깁니다. 사진을 업로드하기 전에 클라이언트에서 암호화하나요, 아니면 서버 권한과 전송 암호화로만 보호하나요?

다음 항목에 관해 물어보세요.

• 사진과 동영상
• 문서
• 음성 메시지
• 링크 미리보기
• 썸네일
• 임시 업로드 파일
• 캐시된 미디어
• 다운로드 권한 부여

미디어 보호는 ‘메시지’에 관한 포괄적인 설명 속에 감출 것이 아니라 별도로 설명해야 합니다.

암호화된 바이트에 대한 접근과 복호화 키에 대한 접근도 따로 물어보세요. 일부 설계는 제한이 덜한 저장 공간을 통해 암호화된 첨부파일을 배포합니다. 이것이 곧 평문 노출을 뜻하지는 않습니다. 핵심은 무단 사용자가 읽을 수 있는 미디어나 키를 얻을 수 있는지, 그리고 저장 경로가 어떤 메타데이터를 드러내는지입니다.

3. 암호화 키는 어디에서 생성되고 저장되나요?

암호화의 신뢰성은 키 처리 방식의 신뢰성에 달려 있습니다.

클라이언트 측 E2EE에서는 개인 키 자료가 참여자 기기의 통제 아래 있어야 합니다. 공개 키는 연락처와 암호화 통신을 설정하도록 공유할 수 있지만, 개인 키에는 더 강력한 보호가 필요합니다.

다음 질문에 대한 명확한 답을 찾으세요.

• 개인 키가 기기에서 생성되나요?
• 암호화되지 않은 상태로 업로드된 적이 있나요?
• 제공업체가 키를 도출하거나 교체할 수 있나요?
• 로그인된 다른 기기가 자동으로 키를 얻을 수 있나요?
• 로컬 키 저장 공간이 보호되나요?
• 키를 초기화하면 어떻게 되나요?
• 앱을 다시 설치하면 새 신원 키가 만들어지나요?

문서가 구현의 모든 세부 사항을 공개할 필요는 없습니다. 그러나 개인 키의 소유 관계와 수명 주기는 설명해야 합니다.

4. 연락처끼리 서로의 키를 검증할 수 있나요?

종단간 암호화가 대화를 보호하려면 암호화 키가 의도한 참여자의 것이어야 합니다.

많은 보안 메시지 시스템은 공개 키를 지문, 안전 번호, QR 코드 또는 다른 검증 값으로 표시합니다.

두 연락처는 다음과 같은 신뢰할 수 있는 경로로 그 값을 비교할 수 있습니다.

• 직접 만남
• 상대가 확인된 음성 통화
• 이전에 인증된 계정
• 신뢰할 수 있는 회사 명부

키 검증은 예상한 키를 사용 중이라는 확신을 더해 주지만, 그 자체로 개인의 신원을 증명하지는 않습니다. 일부 제품은 Signal의 자동 검증처럼 키 투명성 점검도 제공합니다. 모든 제품에 수동 전용 절차를 요구하기보다 지원되는 계정 및 버전 조건을 확인하세요.

지문이 바뀌면 어떻게 되는지도 물어보세요.

키 변경은 초기화, 기기 교체, 복구 작업처럼 정상적인 이유로 발생할 수 있습니다. 하지만 변경 사실은 보여야 합니다. 알림 없이 바뀌면 예상하지 못한 신원 키 변경을 발견하기가 어려워집니다.

5. 서비스는 어떤 메타데이터를 보관하나요?

메시지 내용과 메시지 메타데이터는 서로 다른 범주입니다.

서비스가 E2EE 메시지 본문을 읽지 못하더라도 대화를 전달하고 동기화하며 표시하는 데 필요한 정보는 처리할 수 있습니다.

시스템에 따라 다음 정보가 포함될 수 있습니다.

• 발신자와 수신자의 계정 식별자
• 대화 구성원 정보
• 메시지 타임스탬프
• 전달 및 읽음 확인
• 메시지 크기
• 반응 및 편집 이벤트
• 기기 세션
• 동기화 커서
• 공개 키 자료
• 푸시 알림 토큰
• 악용 방지 및 보안 기록

운영상의 메타데이터가 존재한다고 해서 서비스가 자동으로 안전하지 않은 것은 아닙니다.

중요한 질문은 다음과 같습니다.

• 무엇을 수집하나요?
• 왜 필요한가요?
• 얼마나 오래 보관하나요?
• 누가 접근할 수 있나요?
• 사용자가 내보내거나 삭제할 수 있나요?
• 광고나 관련 없는 프로파일링에 사용하나요?

제공업체가 무엇을 메타데이터로 보는지 정의하지 않고 ‘메타데이터를 전혀 저장하지 않는다’고 주장하면 주의하세요.

6. 계정은 어떻게 인증되나요?

강력한 메시지 암호화도 취약한 계정 보안을 보완하지는 못합니다.

계정을 장악한 공격자는 사용자를 사칭하거나, 새 키를 등록하거나, 서버가 읽을 수 있는 내용에 접근하거나, 복구를 방해할 수 있습니다.

서비스가 다음과 같은 보호를 제공하는지 평가하세요.

• 안전한 비밀번호 처리
• 요청 속도 제한
• 세션 취소
• 명확한 기기 또는 세션 관리
• 인증 정보 재전송 공격 방지
• 안전한 비밀번호 재설정 절차
• 적절한 경우의 다중 요소 인증
• 중요한 계정 변경 알림

계정 인증과 메시지 암호화도 구분하세요.

로그인은 누군가 계정 인증 정보를 가지고 있음을 증명합니다. 그 기기가 원래의 개인 암호화 키를 보유하고 있다는 뜻은 아닐 수 있습니다.

7. 암호화된 복구는 어떻게 작동하나요?

복구는 비공개 메시지 서비스에서 가장 어려운 절충 문제 중 하나입니다.

사용자가 기기를 바꾼 뒤에도 대화 기록에 접근하고 싶어 하는 것은 당연합니다. 그러나 제공업체가 모든 개인 키를 사용자 모르게 복원할 수 있다면 사용자가 예상한 것보다 더 큰 복호화 능력을 가지고 있을 수 있습니다.

보호된 복구 설계는 클라이언트에서 백업을 암호화하고 복구 비밀 정보, 패스키 또는 신뢰하는 기기의 승인을 요구할 수 있습니다. 먼저 백업에 무엇이 들어 있는지 확인하세요. 계정 신원, 연락처, 메시지 기록은 서로 다른 것입니다.

다음을 물어보세요.

• 업로드 전에 백업을 암호화하나요?
• 계정 비밀번호만으로 복원할 수 있나요?
• 제공업체가 복구 비밀 정보를 알고 있나요?
• 지원 담당자가 그 비밀 정보를 초기화할 수 있나요?
• 비밀 정보를 잃으면 어떻게 되나요?
• 복원 후에도 같은 공개 키 지문이 유지되나요?
• 복구 기능을 끌 수 있나요?

신뢰할 만한 답변에는 불편한 한계도 포함될 수 있습니다. 개인 키와 복구 비밀 정보를 모두 잃으면 예전의 암호화된 내용을 복구할 수 없게 될 수 있습니다.

이 결과는 제품 결함이 아니라 실제 보안 경계가 존재한다는 증거일 수 있습니다.

8. 연결이 끊기면 어떻게 되나요?

보안과 신뢰성은 함께 작동해야 합니다.

모바일 연결은 끊기고, 브라우저는 절전 상태가 되며, 기기는 네트워크를 바꿉니다. 잘 설계된 메신저라면 메시지를 중복시키거나 순서를 잃거나 암호화를 약화하지 않고 일시적인 연결 끊김을 처리해야 합니다.

다음 기능을 갖춘 오프라인 및 동기화 모델을 찾으세요.

1. 전송 작업을 로컬에 임시 저장합니다.
2. 안정적인 식별자를 부여합니다.
3. 다시 연결되면 안전하게 재시도합니다.
4. 중복 전송을 방지합니다.
5. 서버의 수신 확인과 상태를 대조합니다.
6. 오프라인 동안 놓친 변경 사항을 가져옵니다.

메시지가 기다리는 동안 앱이 네트워크 전송 데이터와 로컬 발신 대기함을 어떻게 보호하는지는 따로 물어보세요. E2EE가 있다고 해서 로컬 대기열이 저장 상태에서도 암호화된다고 자동으로 입증되지는 않습니다.

네트워크 재시도를 위해 원래 종단간 암호화되는 메시지의 평문 사본을 전달 서비스에 제공해야 해서는 안 됩니다.

9. 업로드와 저장된 객체에는 어떻게 접근 권한을 부여하나요?

미디어 보안에는 암호화 이상의 것이 포함됩니다.

서비스는 아바타, 메시지 첨부파일, 배경화면, 스토리, 임시 업로드, 생성된 썸네일을 처리할 수 있습니다. 각 객체에는 접근 정책이 필요합니다.

앱이 다음을 수행하는지 확인하세요.

• 비공개 미디어를 가져오려면 인증을 요구함
• 요청한 계정이 관련 대화에 속하는지 확인함
• 공개 자산과 비공개 메시지 객체를 분리함
• 연결되지 않은 업로드를 정리함
• 만료된 임시 객체를 제거함
• 계정 간 캐싱을 방지함
• 예측하기 어려운 식별자를 사용하되 예측 불가능성을 권한 부여로 취급하지 않음

비공개 평문 파일은 누군가 URL을 추측했다는 이유만으로 읽을 수 있게 되어서는 안 됩니다. 암호화된 객체라면 키와 접근 권한을 어떻게 배포하고 취소하는지 살펴보세요. OWASP의 권한 부여 지침은 정적 리소스를 포함해 접근 결정을 일관되게 적용하도록 권고합니다. 예측하기 어려운 식별자 하나만으로는 완전한 권한 부여 정책이 되지 않습니다.

10. 그룹 채팅은 다르게 보호되나요?

그룹 암호화와 구성원 제어는 개인 채팅 암호화와 다른 질문을 제기합니다.

구성원 변경, 여러 기기, 메시지 기록, 관리자 역할, 초대, 구성원 제거, 키 교체는 모두 추가적인 설계 요구 사항을 만듭니다.

일부 서비스는 개인 채팅과 그룹 채팅 모두에 E2EE를 제공합니다. 다른 서비스는 개인 대화에만 E2EE를 제공하고, 그룹은 TLS, 인증이 적용된 저장 공간, 서버 측 접근 제어로 보호합니다.

두 번째 모델도 의미 있는 보안을 제공할 수 있지만 신뢰 경계는 다릅니다.

서버가 그룹 내용을 처리할 수 있는지, 다음 상황에서 보호가 달라지는지 물어보세요.

• 구성원이 참여할 때
• 구성원이 나갈 때
• 관리자가 누군가를 내보낼 때
• 메시지가 편집될 때
• 기록이 새 기기로 동기화될 때
• 봇이나 연동 기능이 그룹에 들어올 때

한 대화 유형의 자물쇠가 다른 모든 유형에도 자동으로 적용된다고 가정하지 마세요.

11. 사용자는 어떤 프라이버시 제어 기능을 갖나요?

프라이버시에는 정보가 서비스에 도달한 뒤의 통제도 포함됩니다.

다음과 같은 실용적인 계정 및 대화 제어 기능을 찾으세요.

• 계정 데이터 내보내기
• 계정 삭제
• 세션 취소
• 로컬 또는 동기화된 기록 지우기
• 허용되는 경우 보낸 메시지 삭제
• 읽음 확인 관리
• 프로필 공개 범위 제어
• 원치 않는 연락처 차단
• 알림 미리보기 관리
• 키 백업 비활성화 또는 삭제

제공업체는 삭제가 사용자 자신의 사본만 지우는지, 모든 참여자의 사본을 지우는지, 서버 기록 자체를 지우는지 설명해야 합니다.

수신자가 이미 메시지를 다운로드하거나 복사, 전달, 촬영했을 수 있습니다. 어떤 삭제 기능도 모든 단말에서 완전히 지워진다고 보장할 수 없습니다.

12. 보안 주장은 구체적이고 검증 가능한가요?

가장 충실한 보안 문서는 경계를 정의합니다.

다음 사항에 대한 구체적인 설명을 찾으세요.

• 알고리즘과 키 길이
• 클라이언트 측 작업과 서버 측 작업의 구분
• E2EE가 적용되는 대화 유형
• 미디어 암호화
• 저장되는 정보
• 인증
• 복구
• 키 변경
• 접근 제어
• 알려진 한계
• 문서의 마지막 업데이트 날짜

다음과 같은 모호한 표현은 주의해서 보세요.

• 절대 깨지지 않는 암호화
• 절대적인 프라이버시
• 군용 등급 보안
• 완전한 익명성
• 메타데이터 제로
• 해킹 불가능
• 미래에도 완벽한 암호화

복잡한 통신 시스템을 슬로건 하나로 평가해서는 안 됩니다.

독립 감사, 공개 기술 문서, 재현 가능한 클라이언트, 전문가 검토, 범위가 명확한 보안 보고서는 추가적인 확신을 줄 수 있습니다. 이들이 모두 같은 수준의 증거를 제공하는 것은 아니지만, 근거 없는 최상급 표현보다 유용합니다.

안전한 메시지 서비스의 긍정적인 신호와 경고 신호

긍정적인 신호	경고 신호
제공업체가 어떤 대화가 E2EE인지 명시함	모든 기능을 단순히 ‘암호화’라고 설명함
개인 키의 소유 관계를 설명함	키 처리 방식을 전혀 다루지 않음
키 변경이 보임	키가 알림 없이 바뀔 수 있음
복구의 한계를 문서화함	방법을 설명하지 않고 지원팀이 모든 것을 복원할 수 있다고 함
메타데이터 범주를 나열함	정의 없이 ‘메타데이터 제로’를 주장함
미디어 보호를 별도로 설명함	텍스트 메시지만 언급함
그룹의 신뢰 경계가 정의되어 있음	개인 채팅에 관한 주장이 그룹에도 적용된다고 암시함
보안 페이지에 현재 구현 세부 사항이 있음	마케팅 표현이 기술 문서와 모순됨
한계를 명확하게 밝힘	절대적이거나 깨지지 않는 보호를 주장함

Livara의 공개 주장에 점검표 적용하기

Livara 보안 페이지는 제품 문서를 제공하며 독립 인증이 아닙니다. 현재의 경계는 다음을 구분합니다.

• 개인 메시지: LVR1은 P-256과 ML-KEM-768을 결합한 하이브리드 키 합의 및 지원되는 내용에 대한 인증 암호화를 사용합니다.
• 호환되는 비공개 그룹: LGS1 발신자 키 보호를 사용합니다. 구성원과 역할은 별도의 서버 권한 경계로 남습니다. 오래된 비호환 그룹에 E2EE 표시를 그대로 적용해서는 안 됩니다.
• 공개 채널: 서버가 내용을 읽을 수 있으며 E2EE가 아닙니다.
• 복구: 신원 자료는 업로드 전에 암호화해 봉인됩니다. 이를 복원하는 것은 채팅 기록을 복원하는 것이 아닙니다.
• 메타데이터와 기기: 라우팅 기록과 침해된 단말은 내용 암호화가 약속하는 보호 범위 밖에 있습니다.

이를 설치된 버전과 위협 모델에 비추어 확인할 주장으로 사용하세요. 프로토콜 명세, 로컬 테스트 벡터, 특정 버전 감사, 실제 운영 서비스 관찰은 서로 다른 형태의 증거입니다. 부족한 증거를 완벽한 보안이나 입증된 취약성이라는 가정으로 대신하지 마세요.

60초 안전 메시지 점검표

계정을 만들기 전에 각 질문에 답할 수 있는지 확인하세요.

• 어떤 대화 유형이 종단간 암호화되나요?
• 이미지, 동영상, 문서, 음성 메시지도 포함되나요?
• 개인 키가 참여자의 기기에서 생성되고 보관되나요?
• 연락처끼리 키 지문이나 안전 번호를 비교할 수 있나요?
• 키 변경이 보이나요?
• 개인정보 처리방침에 보관하는 메타데이터가 명시되어 있나요?
• 계정 인증을 설명하나요?
• 키 복구 절차가 일반 로그인과 분리되어 있나요?
• 비공개 미디어 요청에 인증과 권한 확인을 적용하나요?
• 오프라인 대기열에 있는 동안에도 암호화가 유지되나요?
• 그룹과 채널에 정확한 보안 경계가 있나요?
• 과장된 약속 없이 한계를 문서화하나요?

답이 없는 항목은 자동으로 ‘안전’ 또는 ‘위험’으로 판단하지 말고 ‘알 수 없음’으로 표시하세요. 제공업체가 모든 경쟁사와 똑같은 구조를 사용할 필요는 없습니다.

다만 사용자가 무엇을 신뢰하는지 이해할 만큼 정확한 답은 제공해야 합니다.

가장 안전한 선택은 위협 모델에 따라 달라집니다

모든 사람과 상황에서 자동으로 최선이 되는 보편적인 메시지 앱은 없습니다.

가족 그룹, 직장, 기자와 취재원, 의료팀, 공개 커뮤니티는 다음 요소를 서로 다르게 조합해야 할 수 있습니다.

• 기밀성
• 신원 검증
• 익명성
• 그룹 관리
• 메시지 보관
• 규정 준수
• 복구
• 여러 기기 지원
• 오픈소스 코드
• 독립 감사
• 사용 편의성

무엇을 누구로부터 보호하는지 묻는 것부터 시작하세요.

일상적인 개인 통신에서는 계정 도난, 안전하지 않은 네트워크, 기기 분실, 과도한 데이터 수집이 주요 위험일 수 있습니다.

위험도가 높은 통신에는 검증된 신원, 사라지는 메시지 정책, 보안이 강화된 기기, 엄격한 운영 절차, 독립적인 보안 검토도 필요할 수 있습니다.

암호화는 침해된 단말을 고치거나 신뢰하는 수신자가 메시지를 공유하는 일을 막을 수 없습니다.

프라이버시는 정확한 기대에서 시작됩니다

신뢰할 수 있는 메신저는 모든 위험이 사라졌다고 믿으라고 요구하지 않습니다.

다음 내용을 설명합니다.

• 무엇이 보호되는지
• 어떤 기기가 키를 보유하는지
• 서버가 무엇을 처리하는지
• 어떤 메타데이터가 남는지
• 복구가 어떻게 작동하는지
• E2EE가 어디에서 시작되고 끝나는지
• 아직 구현되지 않은 보호가 무엇인지

이러한 명확성은 사용자가 충분한 정보에 근거해 판단하도록 돕습니다.

명확한 문서는 평가에 필요하지만 가장 안전한 앱을 가려내기에는 충분하지 않습니다. 구현 품질, 적시 업데이트, 독립적인 조사 결과, 실제 사용에서의 위험도 중요합니다. EFF의 도구 선택 안내 역시 자신의 위협부터 살피고 개방성을 보장이 아닌 검토 기회로 보도록 권고합니다.

다음 단계로 무해한 시험을 해 보세요. 연락처 한 명을 검증하고, 예시 첨부파일을 보내고, 연결된 기기를 검토하고, 백업 범위를 살핀 뒤 양쪽 참여자가 설정을 안정적으로 사용할 수 있는지 확인하세요. 보호하려는 기밀 자료로 테스트하지 마세요.

자주 묻는 질문

무엇이 메시지 앱을 안전하게 만드나요?

안전한 메시지 앱은 보호된 네트워크 전송, 강력한 인증, 신중한 접근 제어, 안전한 키 관리, 책임 있는 데이터 처리, 명확하게 문서화된 프라이버시 경계를 결합합니다. 비공개 메시지 내용에는 종단간 암호화가 중요한 추가 보호 계층을 제공합니다.

암호화 메시지 앱은 자동으로 프라이버시를 보호하나요?

아닙니다. 앱은 메시지 내용을 암호화하면서도 계정 정보, 타임스탬프, 구성원 정보, 수신 확인, 기기 정보 또는 다른 메타데이터를 처리할 수 있습니다. 프라이버시는 암호화와 서비스 전반의 데이터 처리 관행 모두에 달려 있습니다.

종단간 암호화는 누구에게 메시지를 보내는지도 숨기나요?

반드시 그렇지는 않습니다. E2EE는 주로 지원되는 메시지 내용을 보호합니다. 대화를 전달하고 동기화하기 위해 서비스는 여전히 발신자, 수신자, 구성원, 시간, 라우팅 정보가 필요할 수 있습니다.

메시지 제공업체가 E2EE 메시지를 복구할 수 있나요?

키와 백업 설계에 따라 다릅니다. 제공업체가 암호화된 메시지 기록을 보관하더라도 이를 열 개인 키는 없을 수 있습니다. 복구 시스템은 사용자가 별도의 복구 비밀 정보를 제공할 때만 키를 복원할 수 있습니다.

브라우저 기반 보안 메시지 서비스는 안전한가요?

브라우저는 강력한 클라이언트 측 암호 연산을 수행할 수 있지만, 보안은 여전히 앱 구현, 브라우저 무결성, 기기 보안, 키 저장, 서버의 앱 코드 전달 방식, 사용자의 확장 프로그램과 운영체제에 달려 있습니다.

그룹 채팅은 항상 종단간 암호화되나요?

아닙니다. 그룹에 E2EE를 제공하는 서비스도 있지만 개인 대화에만 적용하는 서비스도 있습니다. 정확한 경계는 제공업체 문서를 확인하세요.

암호화 키가 바뀌면 어떻게 되나요?

새 기기, 재설치, 키 초기화 또는 복구 절차로 키가 바뀔 수 있습니다. 안전한 메신저는 변경 사실을 표시하고 연락처가 새 지문을 검증할 수 있게 해야 합니다.

매우 민감한 통신에 E2EE만으로 충분한가요?

E2EE는 지원되는 단말 사이의 내용을 보호하지만, 감염되거나 잠금 해제된 기기를 보호하거나 수신자의 행동을 보장하거나 메타데이터를 자동으로 숨기지는 않습니다. 위험도가 높은 사용자에게는 강력한 기기 및 운영 보안도 필요합니다.