WhisperVault를 만들었습니다 — 암호화된 자폭 메모와 일시적 채팅방을 주고받을 수 있는 개인정보 우선 툴입니다.
주요 특징:
• 종단간 암호화 (AES-256-GCM)
• 제로지식 설계 — 서버에는 암호문만 보입니다
• 계정 불필요
• 로그 없음, 추적 없음
• 한 번 보기(읽으면 사라짐) 메모
피드백 받고 싶은 항목:
* UX/디자인
* 보안 접근 방식
* 추가했으면 하는 기능
* 헷갈리는 점
* WhisperVault: https://whispervault.pro/
🧐 배경 설명 및 요약
왜 이 글이 올라왔나: 작성자는 본인이 만든 개인정보 중심 메시지 도구를 소개하면서 커뮤니티로부터 UX·보안·기능 관련 피드백을 얻고자 합니다. 핵심은 ‘사용자 프라이버시를 어떻게 보장하느냐’입니다.
작성자가 실제로 묻는 것/걱정하는 것: 사용성(디자인, 기능)과 함께 구현상 신뢰성입니다. 특히 사람들이 자주 묻는 것은 암호화가 클라이언트(사용자 브라우저·앱)에서 수행되는지, 서버가 복호화 가능한지, 코드가 공개되어 독립 검증이 가능한지 등입니다.
어려운 개념을 간단히 설명하면:
• 종단간 암호화(E2EE): 메시지는 보낸 사람 기기에서 암호화되고 받는 사람 기기에서만 복호화됩니다. 중간 서버는 원문을 볼 수 없습니다.
• 제로지식 설계: 서버는 암호문(ciphertext)만 보유하고, 복호화에 필요한 비밀(키)을 알지 못한다는 설계 철학입니다.
• AES-256-GCM: 강력한 대칭 암호화 방식 중 하나로, 기밀성(내용 암호화)과 무결성(변조 감지)을 함께 제공합니다.
• 클라이언트 측 암호화 여부: 진정한 프라이버시 도구라면 암호화·복호화가 사용자 기기에서 일어나야 합니다. 서버에서 암호화를 수행하면 서버 운영자나 서버에 침투한 공격자가 원문을 볼 수 있습니다.
• 로그/메타데이터: ‘로그 없음’은 서버에 메시지 내용이나 접속 기록을 남기지 않는다는 의미지만, 실제 운영에서는 IP, 타임스탬프, 파일 크기 등 메타데이터가 남을 수 있어 주의가 필요합니다.
따라서 독립 검증을 위해 확인해야 할 포인트는: 암호화가 진짜로 클라이언트에서 이뤄지는지(브라우저 콘솔 확인 가능), 암호화 키 관리 방식, 난수 생성 방식, HTTPS 등 전송 보안, 서버 로그 정책, 그리고 코드가 공개돼서 감사를 받을 수 있는지입니다.
댓글 (0)
로그인하고 댓글을 작성하세요.
아직 댓글이 없습니다.