유용한 보안 질문은 암호화가 강력하게 들리는지가 아니라, 무엇을 보호하고 누가 키를 보유하며 어떤 근거가 주장을 뒷받침하는지입니다.
“군사급 암호화”만으로는 메시징 앱을 평가하기에 정보가 부족합니다. 이 표현은 누가 키를 보유하는지, 어떤 대화가 보호되는지, 백업이 평문을 노출하는지, 기기가 침해되면 어떤 일이 일어나는지를 알려 주지 않습니다.
유용한 대응은 암호화를 무시하는 것이 아닙니다. 인상적인 이름표를 확인할 수 있는 구체적인 주장으로 바꾸는 것입니다.
AES-256은 알고리즘 선택이지 완전한 보안 모델이 아닙니다
AES는 공개 표준이며 비밀 군사 기술이 아닙니다. NIST의 FIPS 197은 AES-128, AES-192, AES-256을 규정합니다. 뒤의 숫자는 키 길이를 뜻합니다. 이 표준은 2023년에 편집상 갱신되었지만 알고리즘은 바뀌지 않았습니다.
강력한 암호 알고리즘도 서비스가 평문에 접근할 수 있는 시스템에서 사용될 수 있습니다. 키가 얼마나 긴지만 묻지 말고 누가 복호화할 수 있는지 물어보세요. 키의 생성·저장 방식, 신원 인증 방식, 그리고 어떤 실패 조건에서 앱이 안전하지 않게 계속 작동하는 대신 멈추는지도 확인해야 합니다.
업체가 AES-GCM을 명시한다면 AES만 언급하는 것보다 구체적입니다. GCM은 암호화와 인증을 결합합니다. 그래도 올바른 nonce 처리, 인증 태그 검증, 그 밖의 구현 요건은 중요합니다. 기술적 기준은 NIST의 GCM 명세이며, 로고가 앱의 올바른 구현을 입증하지는 않습니다.
마케팅에서 흔히 한데 묶는 네 가지 서로 다른 주장
| 주장 | 다루는 대상 | 입증하지 못하는 것 |
|---|---|---|
| 전송 암호화 | 앱과 서버 사이처럼 연결을 통한 전송 보호 | 서버가 내용을 읽을 수 없다는 사실 |
| 저장 데이터 암호화 | 특정 키·접근 모델 아래에서 저장된 데이터 보호 | 운영자가 복호화 키를 갖고 있지 않다는 사실 |
| 종단간 암호화 | 지정된 종단점 사이의 내용 보호 | 침해된 종단점의 안전성이나 수신자의 정직함 |
| 양자 내성 키 설정 | 키를 설정할 때 특정 양자 위협에 대한 내성 | 앱 전체 감사, 익명성 또는 미래 보안의 보장 |
전송 암호화가 모든 제공업체의 데이터베이스에 원시 평문이 저장된다는 뜻은 아닙니다. 서비스는 저장 데이터도 암호화할 수 있습니다. 중요한 구분은 제공업체가 키를 통제하는지, 또는 다른 방식으로 읽을 수 있는 내용에 접근하는지입니다. 구호 하나를 다른 구호로 바꾸지 말고 정확하게 설명하세요.
더 폭넓은 입문 설명은 종단간 암호화의 보호 범위에 관한 글을 참고하세요.
“NIST 표준 사용”은 “FIPS 검증 완료”가 아닙니다
FIPS 203은 키 캡슐화 메커니즘인 ML-KEM을 정의합니다. 메신저가 이 알고리즘을 사용한다고 설명하더라도 앱 전체가 인증받거나 독립적인 검토를 받았다는 뜻은 아닙니다. 표준, 알고리즘 시험, 암호 모듈 검증, 제품 보안 감사는 서로 다른 종류의 근거입니다.
NIST의 암호 모듈 검증 프로그램은 승인된 기능을 구현하는 것만으로 FIPS 140 모듈 검증을 입증할 수 없다고 명확히 밝힙니다. 제품이 검증받았다고 홍보한다면 인증서, 정확한 모듈과 버전, 운영 환경, 승인된 구성을 요청하세요. 그다음 그 인증서가 제품의 어느 부분을 실제로 포괄하는지 확인해야 합니다.
이 때문에 “256비트 보안”을 메신저 전체의 일괄 점수처럼 사용해서도 안 됩니다. 프로토콜 조합, 키 관리, 구현에는 각각 다른 한계가 있을 수 있습니다.
비밀번호 인증은 메시지 암호화가 아닙니다
로그인 메커니즘은 사용자가 계정에 접근할 수 있는지를 판단합니다. E2EE는 보호된 메시지 내용을 누가 읽을 수 있는지를 다룹니다. 어느 쪽도 다른 쪽의 특성을 자동으로 제공하지 않습니다.
예를 들어 SRP는 비밀번호 자체를 전송하지 않고 인증하도록 설계되었습니다. 그렇다고 인증 데이터베이스가 도난당해도 무해하다는 뜻은 아닙니다. RFC 5054의 SRP 보안 논의는 검증자 값이 도난당하면 비밀번호 추측 공격과 다른 위험이 생긴다고 설명합니다. “훔칠 비밀번호가 없으므로 서버 침해는 문제가 될 수 없다”는 결론을 피하세요.
독자가 실질적으로 이어서 물어볼 사항은 계정 복구, 활성 세션, 계정 접근 권한과 암호화 키의 관계입니다. “영지식”만 되풀이하는 답변은 중요한 질문을 해결하지 못합니다.
메신저 보안 페이지를 평가하는 다섯 가지 질문
- 어떤 기능을 포괄하나요? 개인 채팅, 그룹, 파일, 통화, 공개 게시물, 백업은 보호 경계가 다를 수 있습니다.
- 사용 가능한 키는 누가 보유하나요? 복구 키, 연결된 기기, 서버 측 처리 모드를 포함하세요.
- 상대 종단점은 어떻게 인증하나요? 키 검증, 의미 있는 변경 경고, 문서화된 신뢰 모델을 찾아보세요.
- 어떤 근거가 있나요? 명세, 재현 가능한 빌드, 테스트 벡터, 독립 감사는 서로 다른 질문에 답합니다. 각각의 버전과 범위를 물어보세요.
- 무엇이 여전히 보이거나 취약한가요? 메타데이터, 침해된 기기, 복사된 메시지, 공개 콘텐츠를 설명에서 빼서는 안 됩니다.
Livara에도 같은 기준을 적용하세요. 보안 문서는 LVR1과 LGS1을 명시하고 운영상의 경계를 공개합니다. 이를 독립 인증이 아니라 평가할 제품의 주장으로 보세요. Proof Lab은 제한적인 시연과 산출물 검사를 제공하며, 모든 기능이나 릴리스가 안전하다는 증거는 아닙니다.
독립 감사 보고서를 읽는 방법
날짜, 감사 주체, 코드 리비전, 포함된 플랫폼, 제외된 구성 요소를 확인하세요. 요약 배지만 보지 말고 지적 사항과 개선 상태를 읽으세요. 암호 라이브러리 감사가 계정 복구, 웹 앱, 알림, 운영 보안까지 자동으로 포괄하지는 않습니다.
감사가 없다는 것은 보안 보증의 공백이지 특정 취약점의 증거가 아닙니다. 반대로 감사도 평생 보장은 아닙니다. 유용한 비교는 보편적인 “가장 안전한” 승자를 선언하는 대신 근거와 그 한계를 기록합니다.
자주 묻는 질문
“군사급”은 언제나 AES-256의 다른 이름인가요?
아닙니다. 이 표현만으로 특정 알고리즘이나 인증을 추론하지 마세요. 업체에 정확히 무엇을 의미하는지 밝혀 달라고 요청하세요.
더 강력한 암호화가 스크린샷이나 악성코드를 막나요?
수신자가 내용을 복사하거나 침해된 기기가 접근 가능한 데이터를 노출하는 것은 막지 못합니다. 이는 서로 다른 위협입니다.
보안 구호보다 더 나은 신호는 무엇인가요?
명확한 범위, 이름이 명시된 프로토콜, 명시적인 한계, 실제 배포된 구현에 관한 검토 가능한 근거입니다. 설명은 무엇을 신뢰할지, 무엇을 더 확인해야 할지 판단하는 데 도움이 되어야 합니다.
