CardanoWall 주소록 만들기

CardanoWall 주소록을 만들려면, 신뢰할 수 있는 연락처를 추가하고 그 사람의 공개 키, 표시 이름, 검증 방법, 그리고 메모를 저장합니다. 연락처마다 항목 하나씩, 모두 본인 계정 아래에 보관됩니다. 한 번 연락처를 저장해 두면, 그 사람에게 파일을 봉인하는 일이 긴 키 문자열을 서둘러 붙여 넣는 것이 아니라 목록에서 이름 하나를 고르는 일이 됩니다.

키를 검증하기 가장 좋은 시점은 급박한 순간이 닥치기 전이지, 그 와중이 아닙니다. 그러므로 시간을 충분히 들이고 실제로 신뢰하는 채널을 쓸 수 있을 때 미리 주소록을 만들어 두십시오.

이 글은 실무 설정 가이드입니다. 이 기능이 내부적으로 어떻게 동작하는지 — 무엇이, 어디에, 왜 본인 계정에 남는지 — 는 주소록은 어떻게 동작하는가를 참고하십시오.

무엇을 먼저 추가해야 합니까?

반복해서 파일을 보내는 사람이나 팀부터 시작하십시오.

예를 들면 다음과 같습니다.

변호사;
감사인;
보도국 담당자;
내부 보안 팀;
컴플라이언스 담당자;
이사회 위원회;
협력 기관;
본인의 백업 신원;
고객사 보안 담당자;
신뢰하는 동료.

주소록을 모든 사람으로 채우려고 하지 마십시오. 키가 가장 중요한 연락처 — 잘못되면 가장 곤란한 상대 — 부터 시작하십시오.

연락처에는 어떤 정보가 필요합니까?

최소한, 표시 이름과 연락처의 서명 공개 키가 필요합니다.

연락처에게 레코드를 봉인하려면, 수신 주소도 함께 저장합니다. 수신 주소는 발신자가 암호화 대상으로 삼는 공개 키이며, 짝이 되는 개인 키는 수신자의 기기를 절대 벗어나지 않습니다. 연락처는 수신 주소를 두 개까지 가질 수 있습니다.

클래식 X25519 수신 주소(age1... 문자열);
선택적인 하이브리드 포스트 양자 수신 주소(age1pqc... 문자열). 포스트 양자 보호가 중요한 장기 보관 자료에 씁니다.

연락처가 서명한 레코드를 인식하려면, 그 사람의 Ed25519 서명 공개 키를 저장합니다. CardanoWall은 모든 연락처에 대해 이 키를 저장하고, 이를 사용해 연락처를 그가 서명한 레코드와 대응시킵니다.

운영상 명확성을 위해, 연락처를 어떻게 검증했는지도 함께 기록하십시오. CardanoWall의 신뢰할 수 있는 연락처 모델은 검증 방법을 — 수동, DNS TXT 레코드, .well-known 페이지, 대면, 또는 QR 전달 중 무엇인지를 — 검증 날짜와 함께 추적합니다.

수신 주소가 처음이십니까? 수신 주소란 무엇인가가 그 개념을 한 페이지로 다룹니다.

연락처는 어떻게 검증해야 합니까?

키를 건네받은 채널과는 별개로, 이미 신뢰하고 있는 채널을 사용하십시오.

좋은 방법으로는 다음이 있습니다.

대면으로 보여 주는 QR 코드를 스캔하기;
수신자의 공식 도메인에 있는 .well-known 페이지 확인하기;
이미 신뢰하는 도메인의 DNS TXT 레코드 확인하기;
영상 통화 중에 키를 대조하기;
기존 암호화 채널로 키를 전달받기;
공식 웹사이트를 통해 공개 프로필 확인하기.

민감한 파일이라면, "이 새 주소를 사용하세요"라고만 하는 단일 메시지에 의존하지 마십시오. 채널이 침해되었다면, 그 채널이 실어 나르는 키 역시 침해되었을 수 있습니다. 무언가를 봉인하기 전에 수신자를 확인하는 것이 핵심입니다. 파일을 봉인하기 전에 수신자를 확인하기가 그 절차를 짚어 줍니다.

표시 이름은 무엇으로 해야 합니까?

몇 달이 지나도 한눈에 알아볼 수 있는 이름을 사용하십시오.

좋은 이름은 구체적입니다.

"Alice Chen — 법무";
"Acme 보안 팀";
"언론 대응 접수";
"이사회 감사 위원회";
"내 오프라인 백업";
"협력사 컴플라이언스";
"Example 보도국 제보".

계정에 시간이 지나며 연락처가 많이 쌓일 수 있다면 "메인", "새 키", "John" 같은 모호한 이름은 피하십시오.

표시 이름은 사람을 위한 편의 장치입니다. 실제 암호학적 식별자는 서명 키이며, 이름은 그저 알맞은 것을 찾기 위한 수단일 뿐입니다.

수신 주소를 둘 다 저장해야 합니까?

연락처가 둘 다 제공한다면, 대개 그렇습니다.

클래식 age1... 수신 주소는 간결하며 일상적인 봉인된 레코드에 적합합니다. 하이브리드 age1pqc... 수신 주소는 장기 보관 민감 자료를 위해 만들어졌으며, 미래의 양자 공격자에 맞서서도 버티는 보호가 필요한 경우에 씁니다. 연락처가 둘 다 공개한다면, 둘 다 저장해 두는 편이 유연합니다. 작성할 때 CardanoWall이 선택한 암호화 모드에 맞는 주소를 사용할 수 있기 때문입니다.

연락처가 하나만 공개한다면, 가진 것을 저장하고 나머지는 나중에 추가하십시오. 서명 키만으로 추가된 연락처는 수신 주소를 직접 입력하기 전까지는 수신 주소가 전혀 없습니다. 그 사람의 서명을 인식하는 데는 문제없지만, 아직 그에게 봉인할 수는 없습니다.

메모에는 무엇을 적어야 합니까?

검증 맥락을 적되, 절대 비밀은 적지 마십시오.

유용한 메모는 다음과 같습니다.

"2026-06-14에 DNS TXT로 검증함";
"사무실에서 QR 전달";
"법적 아카이브에는 하이브리드 주소 사용";
"기기 분실 후 이전 주소에서 교체함";
"공식 보안 페이지 확인됨";
"알려진 번호로 전화 확인됨".

비밀번호, 신원 시드(Identity Seed), 개인 키, 복호화된 파일 내용, 또는 기밀 사건 사실은 연락처 메모에 적지 마십시오. 메모는 이 키를 어떻게 신뢰하게 되었는지를 적는 곳이지, 그 키로 보호하려는 대상을 적는 곳이 아닙니다.

연락처는 어떻게 최신으로 유지합니까?

관계나 키가 바뀔 때마다 검토하십시오.

다음과 같은 경우 연락처를 갱신하십시오.

수신자가 키를 교체할 때;
팀의 담당이 바뀔 때;
외부 계약자가 떠날 때;
공개 프로필이 폐기될 때;
수신자가 새 하이브리드 주소를 공개할 때;
키가 침해되었을 수 있을 때;
그 상대에게 더 이상 레코드를 보내지 않을 때.

오래된 연락처는 즉시 삭제하십시오. 오래된 주소는 주소가 없는 것보다 더 나쁩니다. 실제로는 그렇지 않을 수 있는데도 알맞은 사람에게 봉인하고 있다는 잘못된 확신을 주기 때문입니다.

작성할 때 이것이 어떻게 도움이 됩니까?

키에 관한 결정을 연락처에 관한 결정으로 바꿔 줍니다.

봉인된 레코드를 만들 때, 사용 가능한 수신 주소가 있는 연락처 중에서 이름으로 고를 수 있습니다. 이는 복사·붙여넣기 실수를 줄이고 반복되는 작업 흐름을 더 빠르게 만듭니다.

예를 들면 다음과 같습니다.

법무 팀이 매번 같은 외부 자문 변호사에게 봉인된 증거 묶음을 보냅니다;
보안 팀이 포렌식 협력사에 사고 자료를 보냅니다;
창작자가 알려진 클라이언트에게 소스 파일을 보냅니다;
보도국이 공개 프로필을 통해 기밀 자료를 받습니다;
회사가 감사인에게 컴플라이언스 증거를 공유합니다.

주소록은 단순한 편의가 아닙니다. 작업 흐름의 기억입니다. 들어오는 레코드를 이미 검증한 사람들로 제한하려면, 받은편지함을 알려진 연락처로 걸러 주는 화이트리스트 모드와 함께 사용하십시오.

팀이 주소록을 공유해야 합니까?

여기서는 신중하십시오.

주소록은 관계와 작업 흐름 — 누구와, 얼마나 자주 이야기하는지 — 을 드러냅니다. 팀에 공통 연락처 집합이 정말로 필요할 수도 있지만, 연락처 공유 관리는 단지 편의가 아니라 조직의 보안 모델에 맞아야 합니다.

신뢰할 수 있는 연락처는 계정별로 저장되므로, 하나의 신원을 공유하는 사람들조차 각자 자신의 연락처 이름표와 메모를 따로 갖게 됩니다. 이는 프라이버시 측면에서 좋을 수 있지만, 키를 검증하고 갱신 사항을 전파하기 위한 명시적 절차가 팀에 필요하다는 뜻이기도 합니다. 가치가 높은 수신자에 대해서는 누가, 언제 키를 검증했는지 적어 두십시오. 팀이 공유 신원으로 일한다면, 공유 팀 신원이 그 절충점을 다룹니다.

요약

급한 발송이 닥치기 전에 주소록을 만들어 두십시오.

각 연락처의 서명 키, 수신 주소, 명확한 표시 이름, 검증 방법, 그리고 유용한 메모를 저장하십시오. 이미 신뢰하는 채널을 통해 검증하십시오. 항목을 최신으로 유지하고 오래된 것은 버리십시오.

그러면 파일을 봉인할 때, 서둘러 붙여 넣은 긴 문자열을 믿는 대신 의도한 바로 그 사람을 고르게 됩니다.

더 읽을거리

해시하고, 서명하고, 봉인하고, 공유하기 — 저장된 연락처에게 파일을 봉인하는 일이 더 넓은 흐름 속에서 어디에 들어맞는지 다룹니다.
이 모든 것의 바탕이 되는 오픈 표준: Label 309, 오픈 소스 코드는 github.com/cardanowall에 있습니다.