可委托 匿名 凭证 (Delanocreds)

此库允许您以匿名方式创建、发行、委托/扩展/限制/转让和验证凭证。

创建根凭证，然后委托添加或删除凭证的能力，而无需透露委托链中任何持有者的身份，包括验证者！

如果您想委托凭证、能力或其他数据而不透露委托者或持有者的身份，这将非常有用。

持有者还可以选择性地证明属性并取消委托者证明所选属性的能力。

项目状态/路线图

API正常工作并正在稳定化，但未来可能会更改。

路线图

• 通过测试
• 基本公共API
• 稳定API
• DelanoWallet（存储、签名、备份凭证）
• DelanoNet（数据交换网络）

委托

委托可以使用几种方式

委托添加条目

我们可以委托添加条目的能力（最多 MaxEntries），但前提是凭证被标记为 extendable，并且可用的条目插槽还没有被之前的委托者全部使用。

即使凭证持有者没有添加附加属性的能力，以下始终成立

• 凭证持有者始终可以将他们的凭证分配给一个新的公钥
• 属性始终可以被持有者选择性地显示或隐藏

重要的是要注意，无论当前持有者是否可以添加条目，凭证始终可以分配给一个新的公钥，这就是使此方案匿名化的原因。

因此，虽然持有者可以限制委托者添加属性的能力，但他们始终可以将凭证分配给具有属性的新公钥。

发行者委托

这是事情变得真正强大的地方。根发行者可以将空白凭证委托给服务器的公钥，使服务器能够在其代表下发行凭证，而无需放弃根密钥！

示例：您想设置一个电子邮件活动，通过电子邮件发送一个凭证给联系人，以证明他们拥有该电子邮件地址。当然，您希望由机器人代替手动处理表单。您向服务器的公钥发放可委托凭证。现在，只有该公钥可以在该空根凭证上发放凭证，如果由于服务器被黑而导致密钥泄露，您也不会泄露您的根密钥。可以在其上添加额外的协议，例如在原始凭证上添加过期日期，使在此日期之后用被盗密钥发放的任何凭证无效。

证明委托

不是一直在线生成证明？没问题！用户实际上甚至可以将凭证的证明委托给另一个（比如，服务器），由其代表生成证明，同样无需暴露任何秘密密钥。用户可以禁用额外的条目，甚至删除条目，限制服务器更改条目属性或证明某些条目的能力。因为所有属性都是使用 Sha2-256 哈希的，服务器甚至不知道属性值！在密钥被盗的情况下，盗贼只能为我们生成更多的证明（感谢您提供的免费服务）。

根发放者选项摘要

• 最大属性条目数：每个 Credential 的最大 Entry 数量。
• 最大基数：每个 Proof 或 Entry 的最大可选 Attributes 数量。

属性

Attribute 可以从任何字节创建，例如 age > 21 或甚至一个 .jpg 文件。这些字节使用 Sha2-256 哈希，这意味着它们也是内容可寻址的！一旦创建了一个 Attribute，就可以通过它的 内容标识符 (CID) 来引用，而不是其值本身。这意味着我们也可以通过它们的 CID 来引用属性，而无需担心泄露属性的实际内容或需要在引用时重新哈希内容。

用于哈希属性的算法是 Sha2-256，长度为 32 字节，这是常见的 32 字节 摘要。如果您尝试使用具有不同哈希或长度的 CID 创建 Attribute，将失败并导致错误。因此，在创建 Attribute 时，请使用此库提供的 Attribute 方法。

use delanocreds::Attribute;

let some_test_attr = "read";

let read_attr = Attribute::new(some_test_attr); // using the new method

// Try Attribute from cid
let attr_from_cid = Attribute::try_from(read_attr.cid()).unwrap(); // Error if wrong type of CID
assert_eq!(read_attr, attr_from_cid);

// Attribute from_cid
let attr_from_cid = Attribute::from_cid(&read_attr).expect("a Sha2-256 hash type"); // Returns `None` if wrong type of CID
assert_eq!(read_attr, attr_from_cid);

如果属性是公开的，则可以将其存储在内容可寻址存储中，如 IPFS。如果属性是敏感的，则可以仅通过其哈希引用属性。

请注意，如果某人同时拥有一个 Credential Offer 和属性或甚至它们的哈希，他们将能够声称拥有 Credential，因此您希望将 Offer 和其关联的属性分开（如果在一起，则安全传输）。

条目

一个 Credential 由一个或多个 Entry 组成。每个 Entry 包含一个或多个 Attribute。条目用于将属性分组。

Attribute Entries:
==> Entry Level 0: [Attribute, Attribute, Attribute]
==> Entry Level 1: [Attribute]
==> Entry Level 2: [Attribute, Attribute]
==> Additonal Entry? Only if 3 < Extendable < MaxEntries

删除

凭证持有者可以从凭证中擦除任何条目，这将移除在该条目上创建任何属性证明的能力。如果您想移除代表者证明特定属性的能力，但仍允许他们证明其他属性，这将很有用。需要注意的是，如果在委托凭证之前移除了证明属性的能力，则整个条目将被删除——而不仅仅是单个属性。如果您仍然希望代表者使用其他属性，您必须创建一个新的条目，包含其他属性，并委托扩展的凭证。

这是通过将凭证中的条目承诺的开启信息置零来实现的，这样就不能创建证明。

绑定

目的是提供以下绑定

• Rust API
• WebAssembly绑定生成器 (wasm32-unknown-unknown)
• WebAssembly接口类型 (WIT)

Rust API

完整的API可以通过查看src/lib.rs测试来获取。下面是如何使用API的小样本。

use anyhow::Result;
use delanocreds::{Issuer, Nym, verify_proof, Nonce, Entry, MaxEntries, Attribute};

fn main() -> Result<()> {
    // Build a RootIssuer with ./config.rs default sizes
    let mut issuer = Issuer::default();

    // Create Entry of 2 Attributes
    let over_21 = Attribute::new("age > 21");
    let seniors_discount = Attribute::new("age > 65");
    let root_entry = Entry::new(&[over_21.clone(), seniors_discount.clone()]);

    // Along comes Alice's (pseudo)nym
    let alice_nym = Nym::new();

    // In order for Alice to be issued a Root Credential from the Issuer, the Nym must be randomized to keep her anonymous
    // as non-randomized Nym's are used only to accept Credentials.
    let alice_nym = alice_nym.randomize();

    // A verifier can demand the nym proof include a nonce to prevent replay attacks, or it can skip with with `None`
    // The nonce can be compared against the Pedersen open randomness in the `NymProof` to verify that a replay
    // attacker isn't reusing a previously generated proof
    let nonce = Nonce::default(); // generates a random nonce for us

    // Give a nonce to Alice so she can generate a NymProof using it
    let nym_proof = alice_nym.nym_proof(&nonce);

    let cred = issuer
        .credential() // CredentialBuilder for this Issuer
        .with_entry(root_entry.clone()) // adds a Root Entry
        .max_entries(&MaxEntries::default()) // set the Entry ceiling
        .issue_to(&nym_proof, Some(&nonce))?; // issues to a Nym

    // Send the (powerful) Root Credential, Attributes, and Entrys to Alice

    // Alice can use the Credential to prove she is over 21
    let (proof, selected_attributes) = alice_nym.proof_builder(&cred, &[root_entry.clone()])
        .select_attribute(over_21.clone())
        .prove(&nonce);

    assert!(verify_proof(&issuer.public, &proof, &selected_attributes, Some(&nonce)));

    // Alice can offer variations of the Credential to others
    let bobby_nym = Nym::new();

    let (offer, provable_entries) = alice_nym.offer_builder(&cred, &[root_entry])
        .without_attribute(seniors_discount) // resticts the ability to prove attribute Entry (note: Removes the entire Entry, not just one Attribute)
        .additional_entry(Entry::new(&[Attribute::new("10% off")])) // adds a new Entry
        .max_entries(3) // restrict delegatees to only 3 entries total
        .open_offer()?;

    // Send to Bob so he can accept the Credential
    let bobby_cred = bobby_nym.accept(&offer)?;

    // and prove all entries
    let (proof, selected_attributes) = bobby_nym.proof_builder(&bobby_cred, &provable_entries)
        .select_attribute(over_21)
        .prove(&nonce);

    assert!(verify_proof(&issuer.public, &proof, &selected_attributes, Some(&nonce)));

    Ok(())
}

特性

优势

与其他匿名凭证方案相比，这种DAC方案具有以下优势

• 属性：用户可以选择性地披露并证明凭证中的某些属性。
• 表达能力：S（选择性披露），R（属性上的任意可计算关系，意味着您可以进行比选择性披露更多的操作）
• 限制：表示在委托期间是否可以对委托者的权力施加限制。
• 选择性匿名性：强大的匿名性保证，意味着在发行/委托和展示凭证期间，没有人能够追踪或了解有关用户身份的信息或超出他们应该展示的信息。
• 凭证大小：O(1)，表示凭证的大小是恒定的。
• 展示大小：O(L)，表示展示的大小随着委托数量的增加而线性增长。
• 未公开属性：O(u)，表示未公开属性的大小随着委托数量的增加而线性增长。

表1. 实际DAC方案的比较

🌓† 需要可信设置，并且与它们的参数相关联的陷门。

🌗♣ 它不支持匿名委托阶段。

🌙∗ 它还允许敌对CA，但没有泄露委托者的密钥。

🌚‡ 我们考虑恶意的发行者密钥CA，并且所有委托者的密钥都可以公开。

哈希

RFC9380建议在BLS12-381曲线上进行哈希时使用扩展消息摘要（XMD）（与用于Sha3 SHAKE的扩展输出函数（XOF）相反）。支持XMD的库有blst和pairing_plus。

测试

cargo test
cargo test --target wasm32-unknown-unknown

速度

该库可以在Intel i5-3470 CPU @ 3.20GHz上在不到400毫秒的时间内生成、发行、委托、证明和验证100个发行属性中的30个选定的凭证。

这对于像公共交通、票务等时间敏感型应用来说已经足够快。

快速基准测试

速度快。从总共96个属性中选择30个，观察到以下每一步的基准测试结果

运行 cargo run --release 后

基准测试变量

• l - 承诺向量长度的上界
• t - 承诺集的基数上界
• n < t - 承诺中每个属性集A_i中的属性数量
• C_i（每个承诺级别相同）
• k - 属性集向量的长度
• k_prime - 可以委托的属性集数量

我们设置了以上参数为 t = 25, l = 15, k = 4, k' = 7 和 n = 10，以涵盖许多不同的用例

假设

• 每次委托凭证时，添加一个属性

文档

cargodoc --workspace --no-deps --open

要增量构建文档，请使用 cargo watch -x 'doc --workspace --no-deps --open'。

在Windows上为Github页面构建文档： ./build_docs.bat

参考

Rust 实现了 https://github.com/mir-omid/DAC-from-EQS，见 论文 (PDF)。