봉인된 레코드를 받는 방법

봉인된 레코드를 받으려면 수신 주소를 공유하고, 소프트웨어가 사용자의 키로 열 수 있는 레코드를 찾도록 맡기면 됩니다. 서버가 대신 채워 주는 사서함은 없습니다. 클라이언트는 공개 Label 309 피드를 스캔하고, 각 봉인된 레코드에 사용자의 수신 키를 시도해 본 뒤, 성공적으로 복호화되는 항목을 보여 줍니다.

이 발상의 전환이 핵심입니다. 받은편지함은 서버가 배정하는 것이 아니라 복호화로 발견됩니다. 체인은 읽을 수 있는 수신자 필드를 절대 싣지 않으며, 게이트웨이는 어떤 레코드가 사용자의 것인지 알 필요가 전혀 없습니다.

봉인된 레코드란 무엇입니까?

봉인된 레코드는 콘텐츠가 암호화된 존재 증명입니다.

공개 레코드는 여전히 평문 해시에 커밋하므로, 그 증명은 나중에 바로 그 콘텐츠가 공개 블록 타임 시점에 존재했음을 보여 줄 수 있습니다. 파일 자체는 암호화되며, 암호문은 Arweave 또는 IPFS 같은 콘텐츠 주소 지정 위치에 저장됩니다 — 체인에는 결코 올라가지 않습니다. (공개 증명의 작동 원리는 Label 309의 작동 방식을 참고하십시오.)

일치하는 키를 가진 사람은 누구나 암호문을 복호화하고, 원본 바이트를 복원하고, 평문 해시를 다시 계산하여, 복호화된 파일이 온체인 커밋과 일치하는지 확인할 수 있습니다. 키가 없는 사람은 봉인된 레코드가 존재한다는 사실만 볼 수 있을 뿐, 콘텐츠는 읽을 수 없어야 합니다.

발신자에게 무엇을 알려 줍니까?

발신자에게는 수신 주소를 알려 줍니다. 그 이상은 필요 없습니다.

Label 309 봉인된 레코드의 수신 주소는 두 가지 형태로 제공됩니다.

age1… — 클래식 X25519 수신 경로.
age1pqc1… — 하이브리드 포스트 양자 수신 경로(X-Wing 구성에서 X25519와 ML-KEM-768을 결합한 형태).

수신 주소는 공개되어 있으며 안전하게 공유할 수 있습니다. 이를 통해 누군가가 사용자에게 레코드를 암호화해 보낼 수 있고, 그 외의 일은 할 수 없습니다. 수신 주소는 사용자의 신원에서 파생되지만, 신원 자체를 드러내지는 않습니다.

발신자에게 신원 시드를 절대 알려 주지 마십시오. 시드는 사용자 신원의 비밀 루트입니다 — 서명 키와 수신 키가 결정론적으로 파생되는 32바이트입니다. 이를 가진 사람은 누구나 사용자인 척 서명하고 복호화할 수 있습니다. (시드가 진짜 백업인 이유는 당신의 신원은 시드입니다에서 더 다룹니다.)

발신자는 레코드를 어떻게 만듭니까?

발신자의 소프트웨어가 봉인을 로컬에서 수행합니다. 큰 흐름은 다음과 같습니다.

발신자가 파일이나 메시지를 고릅니다.
소프트웨어가 평문 해시를 계산합니다.
소프트웨어가 일회용 콘텐츠 키를 생성하고 콘텐츠를 암호화합니다.
각 수신자에 대해 그 콘텐츠 키를 수신자의 수신 키로 감싸, 수신자별 슬롯을 만듭니다.
암호문을 콘텐츠 주소 지정 스토리지(예: ar://)에 업로드합니다.
평문 해시와 봉인 봉투를 담은 Label 309 레코드를 Cardano에 게시합니다.

온체인 레코드는 시점을 증명하고 감싸진 키 슬롯을 싣습니다. 저장된 암호문은 암호화된 파일을 담습니다. 사용자의 개인 키가 곧 자신의 슬롯을 여는 열쇠입니다. 해시·서명·봉인·공유라는 동일한 순서는 해시, 서명, 봉인, 공유에서 차례대로 살펴봅니다.

내 클라이언트는 나를 위한 레코드를 어떻게 찾습니까?

클라이언트는 공개 레코드를 스캔하고 그것을 열어 보려 시도합니다.

일반적인 사서함을 기대한다면 이 부분이 낯설게 느껴집니다. 호스팅형 받은편지함에서는 서버가 각 메시지가 어느 계정에 속하는지 알고 그에 맞게 전달합니다. 봉인된 Label 309 레코드에는 그런 라우팅 정보가 없습니다. 봉투는 감싸진 키 슬롯을 나열하지만, 수신자의 공개 키는 전송 데이터 어디에도 나타나지 않습니다 — 읽을 수 있는 수신자 필드가 없습니다.

그래서 클라이언트는 Label 309 레코드의 공개 피드를 동기화하고, 봉인된 레코드마다 사용자 신원의 수신 키로 열리는 슬롯이 있는지 시험합니다. 이것이 로컬 시험 복호화입니다. 각 슬롯을 풀어 보려는 시도가 전적으로 사용자의 기기에서 이루어집니다. 슬롯이 열리면 그 레코드는 사용자의 것이며, 클라이언트가 받은편지함에 추가합니다. 어느 슬롯도 열리지 않으면 클라이언트는 그 레코드를 무시합니다.

미묘하지만 중요한 결과가 하나 있습니다. 슬롯의 순서 역시 아무것도 누출하지 않습니다. 발신자는 게시 전에 슬롯을 뒤섞으므로, "주 수신자"의 위치조차 아무런 단서를 주지 않습니다.

시험 복호화는 모든 파일을 내려받아야 합니까?

아닙니다. 시험 복호화는 저장된 파일이 아니라 온체인 레코드에 실린 봉투를 대상으로 실행됩니다.

감싸진 슬롯과 작은 인증 태그는 레코드 메타데이터 안에 들어 있습니다. 클라이언트는 그 온체인 바이트만으로도, 어떤 암호문도 가져오기 전에 레코드가 사용자에게 보내진 것인지 판별하고 콘텐츠 키를 복원할 수 있습니다. 이것이 중요한 이유는 암호문이 클 수 있기 때문입니다. 데스크톱 클라이언트는 먼저 어떤 레코드가 사용자의 것인지 발견한 다음, 사용자가 열 때 암호화된 파일을 지연 로딩하거나 설정에 따라 미리 캐시할 수 있습니다.

오프라인 우선 클라이언트에서는 이 분리가 토대가 됩니다.

공개 레코드 피드를 동기화합니다.
봉투를 대상으로 로컬에서 시험 복호화합니다.
원한다면 일치하는 암호문을 캐시합니다.
파일을 열 때 필요에 따라 복호화합니다.
이미 동기화한 모든 것을 네트워크 없이도 사용할 수 있게 유지합니다.

게이트웨이는 실제로 무엇을 알고 있습니까?

게이트웨이는 공개 관찰자라면 누구나 아는 것에 더해, 자신이 운영하는 서비스의 운영상 세부 정보를 압니다.

호스팅형 게이트웨이라면 여기에 계정 활동, API 사용량, 사용자의 견적·게시 흐름, 업로드 활동, 잔액 상태, 네트워크 수준의 인프라 데이터, 그리고 누구나 볼 수 있는 공개 레코드 메타데이터가 포함될 수 있습니다. (경계의 전체 그림은 CardanoWall이 볼 수 있는 것을 참고하십시오.)

게이트웨이가 필요로 하지 않는 것은 사용자의 신원 시드, 사용자의 수신 개인 키, 또는 사용자를 대신해 봉인된 콘텐츠를 복호화하는 어떠한 능력입니다. 여기서의 프라이버시 속성은 "서버가 무엇에 대해서도 아무것도 알지 못한다"가 아닙니다 — 그것은 정직하지 못한 주장입니다. 그보다 더 좁고 더 유용합니다. 수신자 매칭과 복호화가 로컬에서 일어나므로, 읽을 수 있는 수신자 필드는 게시되지 않고 어떤 개인 키도 게이트웨이로 전송되지 않습니다. 게이트웨이는 설계상 수신자를 알 수 없습니다. 수신자로 레코드를 걸러 내려는 어떤 시도도 그냥 무시되는데, 걸러 낼 수신자 칼럼 자체가 없기 때문입니다.

왜 공개 수신자 필드가 없습니까?

공개 수신자 필드는 사회적 관계망을 누출하기 때문입니다.

모든 봉인된 레코드가 누구를 위한 것인지 정확히 밝힌다면, 관찰자는 평문을 단 한 바이트도 읽지 않고도 발신자와 수신자 사이의 관계를 지도화할 수 있습니다. 기밀 워크플로 — 취재팀에 연락하는 제보원, 봉인된 입찰, 에스크로에 맡긴 증거 — 에서는 그러한 노출이 곧 위험의 전부일 수 있습니다.

Label 309는 그 대신 감싸진 키 슬롯을 사용합니다. 레코드는 의도된 키 소유자만 열 수 있는 암호화된 자료를 싣습니다. 관찰자는 어떤 레코드가 봉인되어 있다는 사실과 슬롯이 몇 개 있는지는 볼 수 있지만, 읽을 수 있는 수신자 목록은 볼 수 없습니다.

이것은 완전한 익명성이 아니며, 그렇게 포장해서도 안 됩니다. 슬롯 수, 게시 시점, 외부 메타데이터는 여전히 무언가를 드러낼 수 있고, 시점 상관관계를 무력화해야 하는 발신자는 민감한 타임라인을 벗어나 게시해야 합니다. 이 설계가 제거하는 것은 가장 명백한 누출, 곧 영구 원장에 새겨지는 공개 수신자 칼럼입니다.

신원이 여러 개라면 어떻게 됩니까?

클라이언트는 잠금이 해제된 각 신원을 시도합니다.

개인 레코드용 신원 하나, 회사용 신원 하나, 법무 접수용 신원 하나, 고위험 기밀 채널용 신원 하나를 둘 수 있습니다. 각각 고유한 시드와 고유한 수신 키를 가지므로, 한 신원에 봉인된 레코드는 그 신원의 키를 시도하기 전까지 다른 신원에게는 보이지 않습니다.

오프라인 우선 클라이언트는 각 신원이 레코드 피드를 어디까지 스캔했는지 독립적으로 추적합니다. 바로 이 독립성 덕분에 나중에 오래된 시드를 가져오더라도 클라이언트가 그 신원에 대해 피드 전체를 다시 스캔할 수 있습니다 — 오늘부터 시작해 가져오기 이전에 보내진 것을 소리 없이 놓치는 일이 없습니다.

오래된 신원 시드를 복원하면 어떻게 됩니까?

호환 소프트웨어는 시드에서 동일한 수신 키를 결정론적으로 다시 파생합니다.

즉, 오래된 시드로 오래된 봉인된 레코드를 찾을 수 있습니다 — 그 레코드가 여전히 체인에 있어 스캔할 수 있고, 암호문을 여전히 가져올 수 있거나 캐시되어 있는 한 말입니다. 클라이언트는 공개 피드를 다시 스캔하고, 봉인 봉투를 시험 복호화하며, 그 신원의 받은편지함 화면을 다시 구성합니다. 시드를 복원하면 그 신원을 위한 레코드를 인식하는 능력이 복원됩니다 — 게이트웨이는 되돌려 줄 비공개 사서함을 가지고 있지 않습니다.

이것이 시드가 그토록 중요한 가장 분명한 이유 중 하나이며, 신원 시드가 여전히 주목받아야 하는 이유이기도 합니다. 수신자 신원의 시드를 잃어버리면, 그 신원에 보내진 봉인된 레코드를 읽지 못하게 될 수 있습니다 — 공개 증명은 여전히 체인에 남아 계속 검증되더라도 말입니다. 암호화에는 설계상 복구용 백도어가 없습니다. 시드가 곧 복구 경로입니다.

데스크톱 클라이언트가 오프라인에서 레코드를 받을 수 있습니까?

이미 동기화해 둔 것만으로도 작동할 수 있습니다.

CardanoWall Desktop — 오픈소스 Rust SDK(github.com/cardanowall) 위에 Tauri로 만든 오픈소스 Rust 애플리케이션 — 은 정확히 이 원리를 중심으로 설계되었습니다. 레코드를 동기화하고 암호문을 캐시한 뒤에는, 네트워크 연결 없이 그 로컬 데이터를 나열하고 검색하고 검증하고 복호화합니다. 아직 동기화되지 않은 레코드가 있거나 암호문을 아직 가져오지 않았다면, 그것을 가져오기 위해 네트워크가 필요합니다 — 그리고 소리 없이 실패하는 대신 그 사실을 분명히 알립니다.

이는 제대로 된 이메일 클라이언트가 동작하는 방식과 같습니다. 오프라인이라고 해서 세상이 멈추지는 않습니다. 네트워크가 돌아올 때까지 로컬 미러, 캐시, 볼트가 진실의 원천이 됩니다. (오프라인 모델에 관해 더 보려면 오프라인 증명과 CardanoWall Desktop을 참고하십시오.)

누가 레코드를 보냈는지 어떻게 확인해야 합니까?

봉인된 레코드를 받았다는 것은 사용자의 키로 그것을 열 수 있다는 사실만 증명합니다. 누가 보냈는지는 증명하지 않습니다.

Label 309에서 작성자 표시는 선택 사항입니다. 레코드에 서명이 실려 있다면, 그 서명은 특정 키가 그 레코드를 보증했음을 보여 줍니다 — 다만 그 키가 누구의 것인지 판단하려면 여전히 맥락이 필요합니다. 레코드에 서명이 없다면, 발신자가 의도적으로 어떤 신원도 결부하지 않았을 수 있으며, 이는 일부 기밀 워크플로가 정확히 요구하는 바입니다.

민감한 자료라면 발신자 키와 수신 주소를 별도 경로로 확인하십시오. 주소록을 관리하고, 키 지문을 대조하고, 이미 신뢰하는 디렉터리나 직접 확인을 사용하십시오. 암호화는 콘텐츠를 보호하지만, 어떤 키와 대화하고 있는지를 판단하는 일은 별개의 인간적인 신뢰 결정입니다. 주소록의 작동 원리는 주소록의 작동 방식에서 다룹니다.

무엇이 잘못될 수 있습니까?

가장 치명적인 실패는 시드를 잃는 것입니다. 수신자 신원의 신원 시드를 잃으면, 그 신원에 보내진 레코드를 복호화하는 능력을 잃을 수 있습니다 — 그 신원에 한해 영구적으로 말입니다.

나머지는 운영상의 문제이며, 좋은 소프트웨어라면 이를 숨기기보다 정직하게 드러내야 합니다.

암호문이 애초에 성공적으로 업로드되지 않았습니다.
스토리지 위치를 일시적으로 사용할 수 없습니다.
발신자가 잘못된 수신 주소를 사용했습니다.
사용자가 잘못된 신원을 가져왔습니다.
로컬 기기가 침해되었습니다(잠금이 해제된 기기에서 악성 프로그램이 메모리상의 비밀을 읽을 수 있습니다 — 공용 컴퓨터 모드 참고).
레코드가 너무 새것이라 사용자가 요구하는 확인 깊이에 아직 이르지 못했습니다.
레코드는 유효하지만 서명이 없어, 발신자 신원이 확립되지 않았습니다.

증명 시스템은 불확실성을 덮어 가리는 것이 아니라 드러냄으로써 신뢰를 얻습니다.

요약하면

봉인된 레코드를 받으려면 다음과 같이 하십시오.

수신 주소를 공유합니다.
신원 시드를 안전하게 보관하고 백업합니다.
클라이언트가 공개 Label 309 피드를 스캔하도록 둡니다.
로컬에서 시험 복호화하도록 둡니다.
사용자의 키로 복호화할 수 있는 레코드를 열고 검증합니다.

받은편지함은 사용자의 계정으로 주소가 지정된 메시지들의 서버 측 목록이 아닙니다. 그것은 사용자의 신원이 열 수 있는 봉인된 레코드의 로컬 화면이며 — 바로 이 점이 게이트웨이를 사용자의 사적인 서신 밖에 머물게 합니다.

마지막으로 한계에 관한 정직한 한마디. 봉인된 레코드는 키 소유자를 위해 평문을 암호화된 상태로 지키지만, 익명성을 보장하지는 않으며, 그것을 복호화한 사람은 이후 평문을 누설하기로 선택할 수 있습니다. 증명은 특정 바이트가 공개된 시점에 존재했음을 보여 줍니다. 진실이나 소유권, 작성자를 증명하지는 않습니다 — 증명이 증명하지 못하는 것을 참고하십시오.

더 읽어 보기

수신 주소란 무엇입니까?
파일을 봉인하기 전에 수신자를 확인하십시오
공개 파일 없는 기밀 공개
오픈 표준과 그 참조 코드: label309.org와 github.com/cardanowall. Label 309는 Cardano CIP 절차에 제출되어 검토 중입니다.