Zcash中的keys和addresses

1. 引言

【还有个$ock$：outgoing cipher key，用于encrypt an outgoing ciphertext。】

在Zcash协议中，用户若想接收shielded payments，则其必须拥有a shielded payment address，该shielded payment address 可由 a spending key 生成。

相比于Sprout，Sapling中增加了更多的key类型。下图中的箭头指向表示了key之间的衍生关系；双线型表示的相同的key，只是做了不同的抽象。

在Sprout中，有：

• receiving key $s{k}_{enc}$
• incoming viewing key $ivk=(a_{pk},s{k}_{enc})$
• shielded payment address $add{r}_{pk}=(a_{pk},p{k}_{enc})$

Sprout中的这些key都衍生自spending key $a_{sk}$

下图摘自博客 Zcash - 各种密钥和签名，你懂吗？：

在Sapling中，有：

• Spending key $sk$，为256bit的random值。

• Expanded spending key $(ask,nsk,ovk)$，其中$ask$为Spend authorizing key，$nsk$为nullifier private key，$ovk$为outgoing viewing key。$ask,nsk$均为scalar field值，$ovk$为32byte值。
  

• Proof authorizing key $(ak,nsk)$，其中$ak$为Jubjub Point，与$ask$的关系为$ak=ask\ast \text{Jubjub.SpendingKeyGenerator}$。

let ak = fixed_scalar_mult(ask, FixedGenerators::SpendingKeyGenerator);

• Full viewing key $(ak,nk,ovk)$，其中$nk$为Jubjub Point，与$nsk$的关系为$nk=nsk\ast \text{Jubjub.ProofGenerationKey}$。

let nk = fixed_scalar_mult(nsk, FixedGenerators::ProofGenerationKey);

• Incoming viewing key $ivk$，取值范围为$[1,2^{251}-1]$，根据$ak,nk$计算获得。

#[no_mangle]
pub extern "system" fn librustzcash_crh_ivk(
    ak: *const [c_uchar; 32],
    nk: *const [c_uchar; 32],
    result: *mut [c_uchar; 32],
) {
    let ak = unsafe { &*ak };
    let nk = unsafe { &*nk };

    let mut h = Blake2s::with_params(32, &[], &[], CRH_IVK_PERSONALIZATION);
    h.update(ak);
    h.update(nk);
    let mut h = h.finalize().as_ref().to_vec();

    // Drop the last five bits, so it can be interpreted as a scalar.
    h[31] &= 0b0000_0111;

    let result = unsafe { &mut *result };

    result.copy_from_slice(&h);
}

• diversified shielded payment address $add{r}_d=(d,p{k}_d)$（由Diversifier $d$和 Transmission key $p{k}_d$组成）。diversifier $d$为88bit随机值，要求存在与$d$对应的diversified base $g_d=DiversifyHas{h}^{Sapling}(d)$。【可借助encodePaymentAddress()函数，将$d,p{k}_d$组合成一串单一的shielded payment address。】

#[no_mangle]
pub extern "system" fn librustzcash_check_diversifier(diversifier: *const [c_uchar; 11]) -> bool {
    let diversifier = sapling_crypto::primitives::Diversifier(unsafe { *diversifier });
    diversifier.g_d::<Bls12>(&JUBJUB).is_some()
}

根据$ivk$和$d$ 可生成相应的diversified transmission key $p{k}_d$，$p{k}_d$为Jubjub point。

#[no_mangle]
pub extern "system" fn librustzcash_ivk_to_pkd(
    ivk: *const [c_uchar; 32],
    diversifier: *const [c_uchar; 11],
    result: *mut [c_uchar; 32],
) -> bool {
    let ivk = read_fs(unsafe { &*ivk });
    let diversifier = sapling_crypto::primitives::Diversifier(unsafe { *diversifier }); //此处即为Diversify Hash函数。
    if let Some(g_d) = diversifier.g_d::<Bls12>(&JUBJUB) { 
        let pk_d = g_d.mul(ivk, &JUBJUB);

        let result = unsafe { &mut *result };

        pk_d.write(&mut result[..]).expect("length is 32 bytes");

        true
    } else {
        false
    }
}

对于每个spending key，对应有a default diversified payment address with a “random-looking” diversifier。若无法区分default address和以上通过random diversifier生成的地址，则可实现不暴露diversified addresses as a user-visible feature。但是实际zcashd wallet中并未使用default diversified payment address，而是采用ZIP-32 中的方案来生成
注意，整个协议中使用Bech32.encode()是可能产生vanity address的，从而可能会存在泄漏隐私的问题。软件开发者在实际实现时要注意使用randomly chosen diversifier，同时也建议 diversifiers be randomly chosen unique values used to index into a database, rather than directly encoding the needed data。

Zcash的共识协议不依赖于expanded spending key的构建方式。expanded spending key的构建方式有以下两种：

1. 随机生成spending key $sk$，基于$sk$生成expanded spending key $(ask,nsk,ovk)$。
2. 根据 ZIP-32，其中包含了expanded spending key的superset。该方式已用于Hierarchical Deterministic Wallet中。但是目前Zcash还不支持Hierarchical Deterministic Wallet address。

在zcashd（Zcash的官方客户端软件）中，所有的Sapling keys和addresses都是根据 ZIP-32生成的。

Sapling中的shielded payment addresses、incoming viewing keys、full viewing keys和spending keys均为a cryptographic protocol detail，这些信息正常来说不应直接暴露给用户。但是，user-visible operations需要知悉shielded payment address、incoming viewing key、（或）来自于spending key或extended spending key的full viewing key。
【在Sapling中，对于每一个spending key，其对应的full viewing key可在无spend authority的情况下，识别出incoming和outgoing notes。具体的解决方案为在每个Output description中增加额外的ciphertext。】

用户可 以一个shielded payment address 来接收来自 多方的支付，事实上，这些支付指向的是同一收款人 这一信息并不会暴露在区块链上，即使是对支付方来说，也无法知悉这些支付指向的是同一收款人。但是，若两个支付方勾结比对了收款方对应的shielded payment address，则可完全确定指向的是同一收款人。为了避免这种情况，收款方可为每个支付方创建不同的shielded payment address。

在Sapling中，提供了一种为同一spending authority 高效生成diversified payment addresses的机制，这些diversified payment addresses共享相同的full viewing key和incoming viewing key。创建大量这样的diversified payment addresses并不会给 扫描区块链以获取相关交易 增加额外开销。

密码学传统上将非对称加密中用于加密的key称为“public key”。transmission key中作为public key的为$p{k}_{enc}$或$p{k}_d$。这个public key不需要单独分发，因为其已包含在shielded payment address中。

同时注意，控制shielded payment address的分发在某些应用场景下是必要的。同时，这也有助于减少整个协议对 note encryption中使用的密码学安全性的依赖。【具体可参见Zcash Protocol Specification 4.17节“In-band secret distribution (Sapling)”中的分析，知道某些$p{k}_d$的攻击者可尝试寻找整个密码学系统中的某些假设薄弱点。】

2. Sapling Key Components

Sapling中，有：

• $l_{PRFexpand}为\mathbb{N}=512,l_{sk}为256,l_{ivk}^{Sapling}为251,l_{ovk}为256,l_d为88$ 均为常量。
• ${\mathbb{J}}^{(r)},{\mathbb{J}}^{(r)\ast },{\mathbb{J}}_{\ast }^{(r)},rep{r}_{\mathbb{J}},r_{\mathbb{J}}$ 均为Jubjub相关参数，其中：
  ${\mathbb{J}}^{(r)}$为order-$r_{\mathbb{J}}$ subgroup of $\mathbb{J}$。该subgroup中包含了${\mathcal{O}}_{\mathbb{J}}$。除${\mathcal{O}}_{\mathbb{J}}$之外的，order 为$r_{\mathbb{J}}$的point set表示为${\mathbb{J}}^{(r)\ast }$。
• $FindGroupHas{h}^{{\mathbb{J}}^{(r)\ast }}$为“Group Hash into Jubjub”。返回无效point的概率接近$2^{-256}$。
• $PR{F}^{expand}和PR{F}^{ockSapling}$为Pseudo Random Functions。
• $K{A}^{Sapling}$为Sapling Key Agreement。
• $CR{H}^{ivk}$为$CR{H}^{ivk}$ Hash Function。
• $DiversifyHas{h}^{Sapling}$为$DiversifyHas{h}^{Sapling}$ Hash Function。
• $SpendAuthSi{g}^{Sapling}$ Spend Authorization Signature (Sapling)，为a signature scheme with re-randomizable keys。
• LEBS2OSP为$(l:\mathbb{N})\times {\mathbb{B}}^{[l]}->{\mathbb{B}}^{{\mathbb{Y}}^{[ceiling(l/8)]}}$
  LEOS2IP为 ( l : N ∣ l m o d    8 = 0 ) × B B Y [ l / 8 ] − > { 0 ⋯ 2 l − 1 } (l:\mathbb{N}|l\mod 8 = 0)\times\mathbb{B}^{\mathbb{B}^{\mathbb{Y}^{[l/8]}}}->\{0\cdots 2^l-1\} (l:N∣lmod8=0)×BBY[l/8]−>{0⋯2l−1}。
  LEBS2OSP和LEOS2IP为“Integers, Bit Sequenes, and Endianness”中相关定义。

3. Sapling Payment Addresses

Sapling 的shielded payment address 为$add{r}_d=(d,p{k}_d)$（由88-bit Diversifier $d$和 256-bit Transmission key $p{k}_d$组成）。其raw encoding规则分别为：

• $LEBS2OS{P}_{88}(d)$
• $LEBS2OS{P}_{256}(rep{r}_{\mathbb{J}}(p{k}_d))$

encoding以后再加上某些Human-Readable前缀，如Zcash主网上的shielded payment address以“zs”打头，而Zcash测试网上的shielded payment address则以“ztestsapling”打头。

Shielded payment address 中包含的transmission key $p{k}_d$ 可用于 a “key-private” asymmetric encryption scheme。所谓"key-private"是指，ciphertexts中不会泄露其加密key的信息，只对拥有加密key对应private key（此处也可称为receiving key）的一方可见。该机制主要用于communicate encrypted output notes on the block chain to their intended recipient，拥有receiving key的一方可扫描区块链来获取notes addressed to them 并 decrypt those notes。

4. Sapling Incoming Viewing Keys

Sapling中的$ivk$取值范围为$[1,2^{251}-1]$，实际实现以256-bit表示，其中最高的5个-bit会做置零操作。
Zcash主网上的incoming viewing key前缀为“zivks”，测试网的incoming viewing key前缀为“zivktestsapling”。

5. Sapling Full Viewing Keys

Full viewing key $(ak,nk,ovk)$，其中$ak,nk$为Jubjub point，outgoing viewing key $ovk$ 为32byte值。可将其编码为一个单独的串，编码规则为：

• $LEBS2OS{P}_{256}(rep{r}_{\mathbb{J}}(ak))$
• $LEBS2OS{P}_{256}(rep{r}_{\mathbb{J}}(nk))$
• 32-byte $ovk$

在Zcash主网中，full viewing key前缀为“zviews”，测试网的前缀为“zviewtestsapling”。

在Sapling中，每一个spending key都有相应的full viewing key，full viewing key可用于recognize both incoming and outgoing notes without having spend authority。具体是通过每个Output description中额外的ciphertext——$C^{out}$ 来实现的。详细可见博客 Zcash中的加解密机制。

6. Sapling Spending Keys

Sapling中的spending key 以256-bit表示。
Zcash主网中的spending key前缀为“secret-spending-key-main”，测试网的前缀为“secret-spending-key-test”。

Spending key为私钥的一种，拥有spending key的用户可spend the balance of the associated address。对于shielded address，拥有相应spending key的用户可查看address’ balance and transaction data。

参考资料

[1] Zcash Protocol Specification
[2] 博客 Zcash - 各种密钥和签名，你懂吗？
[3] Zcash Protocol Specification
Version 2021.1.22 [NU5 proposal]
[4] Zcash官方文档