建立你的 CardanoWall 通讯录

要建立 CardanoWall 通讯录，先添加一位可信联系人，保存他们的公钥、一个显示名称、你验证他们的方式，以及任何备注——每位联系人一条记录，全部存放在你自己的账户之下。联系人一旦保存，把文件封存给他们就变成了从列表里选一个名字，而不是在匆忙中粘贴一长串密钥。

验证密钥的最佳时机，是在紧急时刻到来之前，而不是身处其中之时。所以请提前建好通讯录——趁你还能从容行事，并且使用一条你真正信任的渠道。

这是一份实操配置指南。如果你想了解这项功能背后的机制——保存了什么、存在哪里、为什么它始终留在你的账户上——请看通讯录是如何工作的。

应该先添加谁？

从你经常发送的那些人或团队开始。

例如：

你的律师；
你的审计师；
一位新闻编辑室的联系人；
一个内部安全团队；
一位合规官；
一个董事会委员会；
一家合作组织；
你自己的备份身份；
一位客户方的安全联系人；
一位可信赖的同事。

不要试图把每个人都塞进通讯录。先从那些密钥最重要的联系人开始——也就是你最不愿意搞错的那几位。

一位联系人需要哪些信息？

最低限度：一个显示名称，加上该联系人的签名公钥。

如果要把记录封存给某位联系人，你还要保存一个接收地址。接收地址就是发送方加密所用的公钥；与之配对的私钥永远不会离开接收方的设备。一位联系人可以拥有两个接收地址：

一个经典的 X25519 接收地址（一串 age1...）；
一个可选的混合后量子接收地址（一串 age1pqc...），用于那些后量子保护至关重要的长期留存材料。

如果要识别由某位联系人签名的记录，请保存他们的 Ed25519 签名公钥。CardanoWall 会为每位联系人保存这个密钥，并用它把某位联系人与他们签名的记录对应起来。

为了让日后操作时一目了然，也请记下你如何验证了这位联系人。CardanoWall 的可信联系人模型会记录一种验证方式——手动、DNS TXT 记录、.well-known 页面、当面，或扫码交接——并附上你完成验证的日期。

初次了解接收地址？什么是接收地址用一页篇幅讲清楚这个概念。

应该如何验证一位联系人？

使用一条你本就信任的渠道，并且要和递给你密钥的那条渠道彼此独立。

可取的做法包括：

扫描当面出示的二维码；
核对接收方官方域名上的 .well-known 页面；
核对你本就信任的某个域名上的 DNS TXT 记录；
在视频通话中比对密钥；
通过一条既有的加密渠道接收密钥；
通过官方网站确认一份公开资料。

对于敏感文件，不要只凭一条写着「用这个新地址」的消息就采信。如果渠道已被攻陷，它所携带的密钥也可能已被攻陷。在封存任何东西之前先验证接收方，正是这件事的全部意义所在——在封存文件前先验证接收方会带你走一遍流程。

显示名称该怎么取？

取一个你几个月后也能一眼认出的名字。

好名字都很具体：

「Alice Chen——法务」；
「Acme 安全团队」；
「媒体团队收件」；
「董事会审计委员会」；
「我的离线备份」；
「合作方合规」；
「Example 新闻线索」。

如果你的账户随着时间会保存许多联系人，就要避免「主」「新密钥」或「John」这类含糊的标签。

显示名称只是为人提供的便利。签名密钥才是真正的密码学标识——名字只是你用来找到正确那一位的途径。

两个接收地址都该保存吗？

通常应该，只要联系人提供了它们。

经典的 age1... 接收地址很紧凑，用于日常的封存记录完全够用。混合的 age1pqc... 接收地址则是为长期留存的敏感材料而设计的——你希望这份保护即便面对未来的量子攻击者也依然成立。如果某位联系人同时公布了两个地址，把两个都保存下来能给你更多灵活性：在你撰写记录时，CardanoWall 可以根据你选择的加密模式，使用与之匹配的那个地址。

如果联系人只公布了一个，就先保存你手上有的，之后再补上另一个。仅凭签名密钥添加的联系人，在你提供接收地址之前是完全没有接收地址的——这对于识别他们的签名没问题，但你还无法把记录封存给他们。