ReVault, 비밀번호를 나누지 않고 암호화 파일 보내기

파일을 열 사람을 정하고, 각자의 키로 열게 한다

암호화 파일을 보낸 뒤 같은 비밀번호를 다른 메시지로 보내는 대신, 받을 사람의 공개키에 접근 권한을 줄 수 있다. ReVault가 제공하는 공유 방식이다. 수신자는 자신의 개인키로 파일을 열기 때문에 송신자의 개인키나 공통 비밀번호를 넘겨받을 필요가 없다.

개발자는 10월 26일 Hacker News에 프로젝트를 소개하며 언어별 바인딩과 API에 대한 의견을 요청했다. 핵심 결과물은 .lbox 확장자의 Lockbox다. 기본적으로 암호화·압축·서명을 적용하는 휴대 가능한 아카이브이며, 전용 저장 서비스를 거치지 않고 파일 자체를 복사해 전달할 수 있다.

이때 Lockbox와 Vault를 구분해야 한다. Lockbox는 보낼 파일 묶음이고, Vault는 자신의 프로필·키·연락처 등을 관리하는 로컬 보관소다. 동료에게 문서를 공유하는 작업은 동료를 위해 Lockbox를 준비하는 것이지, 자신의 키 보관소를 통째로 건네는 일이 아니다.

공개키 교환, 지문 확인, 파일 권한 부여 순서로 진행한다

상대의 공개키를 얻었다고 그 키가 상대의 것임이 자동으로 확인되지는 않는다. 저장소의 공유 안내는 별도 경로로 지문을 확인한 뒤 연락처 키를 가져오도록 설명한다. 지문은 키를 대조하는 데 사용하는 식별값이다.

1. 수신자가 자신의 프로필 공개키를 내보낸다. 공유 대상은 개인키가 아니다.
2. 송신자가 수신자와 통화 등 별도 경로로 지문을 대조하고, 확인한 공개키를 연락처로 등록한다.
3. 그 연락처를 수신자로 지정해 Lockbox를 만들거나, 기존 Lockbox에 접근 권한을 준다.
4. 권한을 반영한 파일을 전달한다. 수신자는 자신의 키로 연다.

키를 연락처에 등록하는 일과 특정 파일을 열도록 허용하는 일은 구분된다. 이 구분 덕분에 연락처를 알고 있다는 이유만으로 모든 파일을 공유할 필요가 없다. 포맷 문서도 아카이브의 내용 키와 그 키에 접근하는 수신자별 키 슬롯을 나눠 설명한다.

키 서버는 공개키 전달을 돕지만 상대를 보증하지 않는다

ReVault에는 공개키 교환을 위한 키 서버도 있다. 게시자가 이메일을 확인하고 키를 올린 뒤 발급 코드를 전달하면, 상대는 그 코드로 공개키 후보를 받을 수 있다. 개발자는 이 서버를 아직 실험 단계라고 소개한다.

코드를 통해 받은 키도 별도 지문 확인을 거쳐야 한다. 저장소 설명은 서버가 프로필의 신뢰를 확정하지 않으며 개인키 저장소도 아니라고 명시한다. 파일을 열 자격을 어느 키에 줄지 판단하는 일을 서버의 이메일 확인으로 대신할 수는 없다.

이 구조에서 키 서버와 파일 전달은 서로 다른 역할이다. 키 서버는 공개키를 교환하는 창구이고, 실제 Lockbox는 이메일 첨부 등 별도 방식으로 보낼 수 있다. 공개키 파일을 직접 교환하는 흐름도 제공한다.

권한을 지워도 이미 보낸 복사본이 사라지지는 않는다

현재 파일에서 수신자 접근을 제거하는 기능은 있다. CLI 문서는 키를 제거할 때 이전 키 이력이 남지 않도록 현재 Lockbox 상태를 다시 쓰는 과정을 설명한다. 단순히 연락처 이름만 지우는 작업과 다르다.

다만 수정하는 대상은 그 파일이다. 상대가 이미 받아 둔 이전 복사본까지 바뀌는 것은 아니므로, 이를 전송한 문서의 원격 회수 기능으로 이해하면 안 된다. ‘다음에 보낼 파일의 접근 권한을 바꾼다’와 ‘상대가 가진 파일을 못 열게 한다’는 서로 다른 결과다.

도입 단계도 구분할 필요가 있다. 제작자는 HN에서 베타라고 소개했지만 저장소 README는 Rust 구현을 알파로 표시하며 파일 형식과 공개 API가 바뀔 수 있다고 밝힌다. 현재는 정식 출시 전 도구로 평가하고, 시험용 파일로 키 교환과 수신자의 열기 과정을 먼저 확인할 단계다. ReVault의 제안은 비밀번호 전달을 수신자별 키로 바꾸는 것이며, 그 출발점은 정확한 공개키 확인이다.