G-Merkle：基于哈希的群签名方案

G‐Merkle：一种基于标准假设的基于哈希的群签名方案

1 引言

后量子密码学正受到越来越多的关注，因为美国国家标准与技术研究院[oSN16],美国国家安全局[NSA15]以及PQCRYPTO项目[PQC16]均支持从经典方案向后量子方案迁移。基于哈希的签名（HBS）被认为是良好的候选方案，因为它们提供了良好的安全性和性能保障。这些签名被认为是抗量子的，而广泛部署的公钥密码系统容易受到多项式时间量子攻击的影响[Sho94],并且仅依赖于最小假设，即与哈希函数相关的一些经过充分研究的安全概念。请注意，任何带有附加消息的签名方案（经典或后量子）也依赖于哈希安全性（用于将任意长度消息映射为固定长度摘要），以及一些其他（可能研究较少）的假设。

HBS的另一个优势在于其实际性能。与需要昂贵计算的传统方案不同，HBS仅需哈希计算，该操作的性能更接近对称密钥加密而非公钥密码系统。鉴于其高效率和紧密安全性，HBS可被视为极少数能够立即替代传统密码系统的后量子密码学替代方案之一（尽管有状态方案可能需要额外注意状态管理[MKF+16]）。然而，正是这种带来高效率和紧密安全性的简洁性，也限制了构建群签名等更复杂结构的能力。

群签名允许群组中的任何成员代表该群组匿名签署消息。这是通过一个对所有群成员都相同的唯一群公钥来实现的。群管理员可以通过主密钥打破任何群签名的匿名性，从而确定相应的签发者（可追溯性）。需要注意的是，除群管理员外，没有任何其他实体能够获取信息或将签名追溯到任何群成员（匿名性）。群签名方案在现实世界中具有广泛的应用，例如远程认证协议、交通管理、电子商务、电子现金、电子拍卖等。

1.1 相关工作

首个群签名方案由[Cv91]提出，随后在[ACJT00]中得到改进。完全匿名性与完全可追溯性的概念可追溯到[BMW03],提出的安全模型，一旦这些概念在方案中得以实现，便能提供更强的安全性质。自那以后，基于经典假设的大量实用构造被提出。这些方案可分为基于随机预言的构造[ACJT00,CL02,CL04,DP06]和标准模型下的变体[BWM03,BSZ05,BW06,BW07,Gro07]。所有这些构造在很大程度上都基于Groth‐Sahai非交互式证明系统（NIZK），适用于多种语言。在[BL09],中，Brickell和Li提出了具有先进性质的EPID，例如基于签名的撤销和基于私钥的撤销。目前仅有少数（安全的）构造基于被认为具有抗量子特性的计算问题。这类方案主要基于格上的困难假设[GKV10,LLLS13,LLNW14,NZZ15,LNW15]，或基于编码的方案[ELL+15]，但后者依赖于额外的（非标准）假设。

然而，所有这些构造都需要针对特定语言（如[MV03]）的昂贵的非交互式零知识论证。此前，似乎很难基于哈希函数构建群签名方案，因为哈希函数提供的可利用结构很少。事实上，这方面的研究成果也较少基于哈希函数的特殊属性签名方案的研究。一个例子是Buchmann等人提出的基于单向函数的前向安全签名方案（也包括代理和密钥隔离签名方案）。[BDH11]。最近，已有研究显示，非交互式零知识证明[GMO16]可以通过哈希函数以及多方计算技术构造出来。这为实现高级密码学构造开辟了新的方向，因为NIZK证明系统是一种常用的工具。然而，据我们所知，文献中尚未提出过任何基于哈希函数的群组签名方案。

1.2 我们的贡献

在这项工作中，我们提出了首个（有状态的）基于哈希的群签名方案。我们的方案相较于其他群签名方案具有诸多优势，例如：
– 它非常简单，仅由基于Merkle树的签名方案与安全分组密码或伪随机函数组合构建而成。后者可通过Luby和Rackoff的构造方法基于单向函数实现[LR86],因此可在标准模型下基于最小假设进行构造。这回答了[LNW15]中提出的一个开放性问题。
– 我们不需要像其他群签名方案那样使用昂贵的非交互式零知识证明（例如通过Fiat‐Shamir变换）来证明对秘密的掌握。因此，无需随机预言实例化。
– 它是抗量子安全的，并具有较小的密钥和签名大小，优于所有其他后量子群签名方案。事实上，公钥大小和底层一次性签名大小与单签名者设置中的相同。认证路径随着相关Merkle树包含N个叶节点而增加log N · B个节点，从而使得每个群成员可生成相同数量的签名。这与单签名者设置中的签名数量一致。

为了实现这一功能，我们利用了Merkle树的结构[Mer90]。更准确地说，我们让所有群成员共享同一棵Merkle树，该树在构建之前对其叶节点进行了打乱（通过分组密码或更一般的伪随机置换（PRP）实现）。我们的构造为每个群成员分配了有限数量的B签名。每个群成员也有自己的私钥。在第6节中，我们给出了几种处理与认证路径相关限制的选项，提供了不同的权衡方案。我们强调，这些策略似乎没有一种在所有情况下都是最优的，但我们希望这一讨论能够促进学术界进一步研究如何最优地解决这一特定问题。

在效率方面，对于N个群成员和哈希函数摘要长度n，我们的群签名大小为[|一次性签名| + n ·(log N+log B)]比特，与具有N · B个叶节点的Merkle树签名大小相当。基于格的对应方案至少占用log N · O˜(n)比特（环变体）或log N · O˜(n²)比特（矩阵变体），并且群公钥大小增加了log N倍。此外，底层格问题的强度减弱了log N倍（例如SIVPlog N· O˜（n²），参见[LNW15]）。我们构造的特性直接体现在签名和验证的运行时间上。需要注意的是，其他群签名构造通常依赖于高成本的零知识证明（使用费阿特‐沙米尔变换）来实现群签名方案的各种特性，而我们的构造则免费继承自Merkle树结构。我们的方案可以使用任何（有状态）类Merkle签名方案实例化，例如XMSS Merkle树方案[BDH11,HBGM18]。

在安全性方面，我们在Bellare等人（BMW模型）的著名框架内为完全可追溯性提供了一个证明[BMW03]，以及根据卡梅尼施和格罗特[CG05]定义的匿名性。后者对于基于私钥的撤销机制是必需的，这是一种理想特性，使验证者能够识别由已被撤销的私钥签发的签名。我们还讨论了一个概念验证实现，以展示其在公开可用的树结构中的效率和可扩展性。

1.3 乔姆和范黑斯特的群签名方案

我们的构造可以看作是对乔姆和范黑斯特提出的首个基于离散对数的群签名方案的改进[Cv91]。在他们的最初构造中，每个群成员被随机分配若干安全签名方案的公钥和私钥，每个群成员存储其被分配的私钥集合。为了打开签名，群管理员为每个已颁发的密钥存储对应群成员的名称。群公钥表示为所有公钥的（随机）串联。可以看出，[Cv91]中采用的方法可以扩展到任何常规签名方案。

然而，在我们的构造中，无论签名者的数量和签名的数量如何，群公钥仅由一个单一的哈希值表示。此外，每个签名者只需存储一个秘密种子，所有一次性密钥对和叶节点都从该种子派生。为了以较低成本确保匿名性和可追溯性，群管理员应用伪随机置换来打乱叶节点的位置，并在无需存储大量名称与对应密钥列表的情况下打开签名。所有这些修改都可以直接应用于[Cv91]。

1.4 开放问题

在BMW模型中，完全匿名性将导出一个公钥加密方案[CG05，AW04]，该方案仅基于单向函数的存在性，即群签名方案也可作为构建其他公钥密码原语的基础。然而，实现这一结果的希望渺茫，因为因帕利亚佐和鲁迪奇的开创性工作[IR89]已经表明，无法基于单向函数构建安全密钥协商协议。因此，一个具有挑战性的开放问题在于修改我们的方案以满足更强的完全匿名性要求。获取并存储认证路径是Merkle树构造的一个必要条件，这似乎是本工作难以克服的一个限制，难以规避。最后，我们注意到多树方法（例如[HRB13]）不适用，从而限制了可达到的最大树高度。

1.5 结构安排

第2节介绍初步概念，第3节介绍群签名方案的背景及相关安全概念，第4节提出我们的构造方法。第5节详细描述其安全性评估，第6节讨论认证路径计算，第7节介绍其实现方面，第8节给出我们的结论。

2 预备知识

众所周知[Mer90,BDS08,BDH11]，仅使用安全哈希函数即可构建安全的数字签名方案安全哈希函数。与需要安全哈希函数以及困难的基础计算问题的其他签名方案相比，这是一个优势。从这个意义上讲，基于哈希的签名方案达到了最小安全要求。安全哈希函数的概念较为模糊，需要进一步细化。下面回顾三个与哈希函数相关的计算问题，这些计算问题有助于评估基于哈希的签名方案的安全性。

密码学哈希函数 H：{0, 1}∗ →{0, 1}n是一个可高效计算的函数 H=(H,HKGen)，其中HKGen(1n)输出一个哈希函数 H，而H将输入 H和元素 m ∈{0, 1}∗映射到 H(m) ∈{0, 1}n。根据给定的应用场景，可能需要具备一组特定的性质[Rog04]。

单向性 (OW) 如果对于PPT攻击者来说，找到随机像的一个原像在计算上是不可行的，则称哈希函数 H是单向的。

抗碰撞（CR） 如果对于PPT攻击者来说，难以找到两个不同的消息 m ≠ m′使其映射到相同的哈希值，即 H(m)= H(m′)，则称哈希函数 H是抗碰撞的。

第二原像抗性（SR） 如果对于一个PPT攻击者和给定的一对(m, H(m))，难以找到另一个消息 m ≠ m′使其映射到相同的哈希值H(m)= H(m′)，则称哈希函数 H具有第二原像抗性。我们注意到CR蕴含SR。

为了提供λ比特的经典安全性以抵御碰撞和原像攻击，哈希函数的摘要长度至少需要为n= 2λ比特和n= λ比特，分别。为了在后量子时代维持相同的安全性水平，哈希函数的摘要长度需要扩展3/2倍（针对碰撞）以及2倍（针对原像）。这是由于量子计算机上格罗弗搜索算法[Gro96]带来的加速所致。请注意，这与Shor算法对RSA/ECC密码系统实现的量子加速相比，其量子加速效果微乎其微[Sho94]对抗RSA/ECC密码系统。

大多数基于哈希的签名方案要么是一次性(OTS)，要么是多次签名(MTS)方案。一次性签名(OTS)方案（例如Winternitz[Mer90]和W‐OTS+[Hül13]）存在一个重要限制：一个私钥不能用于签署多于一条消息（否则将失去其安全保证）。由于这一限制，Merkle提出了一种仅基于哈希函数将一次性签名方案转换为多次签名方案的方法。这被称为Merkle树签名方案[Mer90]，它提供了一种将多个一次性公钥绑定到单个多次使用公钥的方法。从这个意义上讲，由这些一次性私钥生成的任何签名都可以通过单一的（多次使用）公钥进行验证。

Merkle方案使用高度为h的二叉树，该树由2^h个一次性密钥对构建而成。叶节点通过一次性公钥的哈希计算得到，内部节点通过对连接的子节点进行哈希计算得到。此规则用于构建从叶节点到根节点的所有内部节点，其中根节点即为多次使用公钥。

3 群签名方案的基础

在本节中，我们参考贝尔等人（Bellare et al.）的研究，介绍与群签名方案相关的各种定义和安全概念。[BMW03]用于根据卡梅尼施和格罗特（Camenisch and Groth）提出的完全可追溯性和匿名性[CG05],，其描述了一套全面的性质。

在我们设定中，适当的匿名性安全模型归功于[CG05],，因为攻击者只能访问被腐蚀用户的私钥，而与[BMW03],不同的是，在后者中攻击者可以完全访问所有群成员的私钥。前一种情况反映了攻击者是静态的，或者他是自适应的且各方无法擦除数据的情形（在这些情况下，完全匿名性不会增强安全性）。在我们的方案中，对于具有擦除能力的自适应攻击者和参与方，我们并未实现[BWM03]意义上的完全匿名性，因为一旦公开私钥，就能立即识别出所有相关的签名。但对于仅基于单向函数存在的构造而言，这似乎是合理的。我们注意到，一旦我们的基于哈希的群签名方案也满足[BMW03]定义的完全匿名性，就可以由此构建一个公钥加密方案。这在后量子密码学中将是一个重大成果，因为它意味着仅基于单向函数安全性（最小假设）即可实现公钥密码学（见第8节）。在第8节中，我们简要讨论了如何根据[CG05、AW04]的方法，利用完全匿名性来构造一个公钥加密方案。因此，在安全游戏[CG05]中，攻击者会获得一个随机签名，并必须输出该签名对应的正确身份，且该身份在此之前未被腐蚀。我们在匿名性游戏中考虑到了有状态类Merkle方案仅能输出有限数量签名的事实。

在一个群签名方案中，主要涉及三个参与方：

• 群管理员 他实例化该方案并生成群公钥。他为每个群成员分配一个私钥。在群签名被滥用或发生不当行为的情况下，群管理员有权使用其主密钥揭示群签名对应的身份。
• 群成员 群成员可以使用其私钥对任意数据进行签名，使得除群管理员外的任何验证者均无法知晓其身份。
• 验证者 任何验证者都可以使用群公钥来验证群签名。他仅知道某个群成员签署了该数据，但无法确定是哪一个群成员。

The s群签名方案的语法及其涉及的算法如下 s.

语法 ：一个群签名方案由以下多项式时间算法组成 GS= (G.KGen,G.Sign,G.Verify, G.Open)。

• G.KGen(1k, 1N) : 群密钥生成算法是一个随机化算法，它以安全参数 k和用户数量 N作为输入，生成并输出群公钥gpk、与第 i个群成员相关的群签名密钥 gski（其中 i ∈[N]），以及群管理员用于打开签名的群主密钥或追踪密钥 gmsk。
• G.Sign(gski, m) : 群签名算法以群签名密钥gski和消息m ∈{0, 1}∗ 作为输入，并输出对该消息的群签名σ。
• G.Verify(σ, m,gpk) : 确定性群验证算法以群签名、消息和群公钥作为输入，若签名有效则输出1，否则输出0。
• G.Open(gmsk σ, m) : 群组打开算法是一个确定性算法，输入为群主密钥、一个签名以及对应的消息，输出与 σ相关的身份。

该方案要正常工作需满足两个基本条件。具体而言，必须保证验证和追踪过程的正确性要求对所有诚实生成的签名都成立。也就是说，对于任意群成员i ∈[N]，以下两个表达式成立的概率除了可忽略的情况外均应成立

G.Verify(G.Sign(gski, m), m, gpk)= 1
G.Open(gmsk, G.Sign(gski , m), m)= i.

第一个要求主要意味着所有诚实生成的群组签名必须是有效的。而第二个表达式允许群管理员利用主密钥来恢复正确生成的签名的身份。

我们现在回顾一下由[BWM03] Bellare等人引入的与群签名方案相关的安全概念，随后在[BBS04] Boneh等人中进行了宽松化。在该宽松版本中，攻击者不被允许对打开过程进行预言机访问。关于匿名性，我们参考以下安全模型：卡梅尼施和格罗特[CG05],其中攻击者确实能够访问被攻破的群成员的私钥。该模型尤其还涵盖了实现基于私钥的撤销的可能性，这在远程认证协议中是一项有用的功能，因为一旦某个身份的私钥被泄露（例如从TPM中被提取），可能需要识别该身份的所有签名，以防止潜在的攻击者以此身份进行签名。根据这些模型[BWM03,CG05],一个群签名方案需要确保两个主要的安全特性，我们将在下文详细阐述。

3.1 匿名性

未掌握群主密钥的攻击者无法从群签名中揭示群成员的身份。在相应的安全游戏中，遵循[CG05]的模型赋予攻击者打开权限，以允许攻击者查看已打开的签名中的身份信息。然而，这些模型需要进行修改，以考虑群成员能够签发的签名数量受限的情况。因此，对于被攻破的群成员，攻击者可以任意多次调用打开和签名预言机（最多 B次）。对于诚实方，每个签名者最多只能打开B −1个签名。

我们区分SPRP‐匿名性与PRP‐匿名性：前者严格遵循[CG05],的匿名性游戏，而后者不允许攻击者访问打开预言机。之后我们将证明，一个伪随机置换（例如安全的分组密码）可用于实例化该方案，以满足上述任一种匿名性概念（图1）。

定义1 (SPRP‐匿名性 [CG05]) 。 形式上，由算法 GS= (G.KGen,G.Sign,G.Verify,G.Open)定义的群签名方案被称为匿名的，如果对于所有可访问开启和签名请求器的概率多项式攻击者 A以及所有多项式有界的 N，该攻击者在实验ExpSPRP , an GS A ,(k, N, B)中的优势是可忽略的

AdvSPRP, GS A an−b(k, N, B)= |P[ExpSPRP,an−1 GS,A (k, N, B)= 1] − P[ExpSPRP,an−0 GS,A (k, N, B)= 1]|.

我们还定义了一种较弱的匿名性形式，考虑了[BBS04]中所讨论的放宽条件。具体而言，在该实验中，攻击者无法访问打开预言机。正如我们稍后将看到的，这将使我们仅使用安全分组密码即可实例化该方案。

定义2（PRP‐匿名性） 。由算法 GS=(G.KGen,G.Sign,G.Verify,G.Open)定义的群签名方案称为具有匿名性的，如果对于所有能够访问签名预言机的概率多项式攻击者 A以及所有多项式有界的 N，攻击者在实验ExpPRP, an GS A ,(k, N, B)中的优势是可忽略的

AdvPRP,an−b GS,A (k, N, B)= |P[ExpPRP,an−1 GS,A (k, N, B)= 1] − P[ExpPRP,an−0 GS,A (k, N, B)= 1]|.

参见图2。

3.2 完全可追溯性

该功能允许群管理员或主密钥持有者撤销签名者的匿名性并揭示其身份。如果检测到不当行为或私钥滥用，这种机制尤为重要。实际上，这一概念的强度更高，因为它要求任何共谋方组成的集合都无法生成无法被群管理员打开或无法追溯到某个群成员的签名，即使这些共谋方能够访问主密钥（例如在密钥生成过程中提取的主密钥）。我们注意到，在此模型中，不要求对交换的签名数量设置上限。

定义3 (完全可追溯性 [BMW03]) 。 形式上，群签名方案 GS= (G.KGen,G.Sign,G.Verify,G.Open)被称为完全可追溯的，如果对于所有可访问打开预言机的概率多项式攻击者 A以及所有多项式有界的 N，该攻击者在实验 Exp f −trace GS A ,(k, N)中的优势是可忽略的

Advf −trace GS,A(k, N)= P[Exp f −trace GS,A(k, N)= 1].

4 G‐Merkle：一种基于哈希的群签名方案

我们的有状态群签名方案基于Merkle树的使用，类似于单签名者基于哈希的签名方案中的做法。其核心思想是将此方法扩展到多用户环境，其中多个签名者共享同一棵树以签署消息。朝此方向的一个初步尝试是让每个用户生成自己的 Merkle树（如同在单签名者方案中一样）。然后，这些子树可以被附加到一个超级树上，该超级树的叶节点为各子树的根节点。

然而，这种朴素的构造无法满足群签名方案所要求的不可链接性属性，因为某个签名者生成的所有签名的认证路径至少会共享一个节点（其子树的根节点）。为了克服这一障碍，我们在树构造之前对叶节点应用一种混合策略。也就是说，在密钥生成阶段，群管理员收集所有参与方的叶节点集合，并随后对该集合应用一个安全的均匀随机置换。该置换将打乱叶节点在合并后集合中的索引及其对应位置。然后，按照前述方式构建超级树。实际上，这是一种实例化基于哈希的群签名方案的通用方法，可视为单签名者设置的一种扩展。由于我们的混合策略基于伪随机置换的使用，我们首先给出一些必要的定义。设 Pn表示置换的集合，且 P ∈Pn满足 P：{0, 1}n −→{0, 1}n。

定义4 。对于函数对(E, D)，其中 E, D:{0, 1}k ×{0, 1}n −→{0, 1}n，若对每个 r ∈{0, 1}k， Er和 Dr互为逆函数，并且对于任意概率多项式对手，其区分伪随机置换与真正随机置换的成功概率满足以下条件：

AdvDist A(k, N)= |PK[AEK,DK(·)= 1] − PP∈Pn[AP,P−1(·)= 1]| ≤ ε

4.1 从单向函数实例化伪随机置换

我们注意到，尽管可以使用分组密码来实例化伪随机置换，但伪随机置换也可以特别地由伪随机函数构建。更准确地说，Luby和Rackoff[LR86]提出利用伪随机函数结合Feistel结构构造伪随机置换的方法。Goldreich等人[GGM86]证明了伪随机生成器可推出伪随机函数，而伪随机函数又可以从任意单向函数导出[HILL93]。这表明，单向函数确实足以构造安全的伪随机置换。下面我们给出一种非常简单的方法，从伪随机函数生成伪随机置换。

定理1 (定理3.1,[NR96]) 。 设 f1， f2为长度为 n和 p1的独立的伪随机函数， p2为长度为 2n的独立置换。定义函数

PRP(p1, f1, f1)= T f1 ◦ T f2 ◦ p1
SPRP(p1,p2, f1, f1)= p −1 2 ◦ Tf1 ◦ Tf2 ◦ p1,

其中Tf i( l, r)=(r, l ⊕ fi( r))对于 |l| = |r| = n且 f1, f2,p1,p2 是独立选取的。那么， PRP(p1, f1, f1)是一个伪随机函数，而SPRP(p1,p2, f1, f1)是一个强伪随机置换。

通过使用合适的伪随机函数，我们可以借助定理1，利用安全的SPRP实例化群签名方案。在这种情况下，整个群签名方案仅基于单向函数的存在性，这是公钥密码学存在的最低要求。

4.2 从分组密码实例化伪随机置换

一般而言，可以应用完全均匀随机置换，即从 n! 个元素的集合中均匀随机选择一个置换。然而，从如此巨大的集合中选择一个元素至少需要 O(nlog(n))比特。对于n> 220，这种方法是不切实际的。

因此，在实践中，通过满足定义4中条件的分组密码（例如AES、SIMON以及许多其他分组密码）来实例化伪随机置换更为高效。更具体地说，函数 EK(·) 和 DK(·) 分别对应于相应分组密码的加密和解密函数。分组密码代表了所有可能置换的一个子集。

分组密码的安全性。 在使用安全分组密码实例化该方案时，为了保证匿名性，攻击者即使看到一定数量 T的（叶位置，群签名者）对（对于SPRP‐匿名性为 T> 0，对于PRP‐匿名性为 T= 0），也无法以不可忽略的优势正确地将剩余叶节点的位置映射到群成员。例如，如果从所有可能置换的集合中采样一个置换，则每个群成员都可能与某个剩余叶节点相关联，前提是该成员尚未签出其所有签名。在实践中，这意味着要么从所有置换的集合中均匀随机选择一个置换（例如，对于具有4个节点的树），要么分组密码的比特安全性大于或等于该方案的目标安全级别。

具有较大输出大小的分组密码。 在实际中，人们找不到能够对10位或20位整数（如h= 10或 h= 20所需）进行置换且安全性超过100位的分组密码。在这种情况下，可以使用更大的分组密码，例如AES‐128或AES‐256。此时树的构造方式略有不同。当管理员接收到所有叶节点后，它生成元组集合 S={(leaf1, EK(1))…,(leaf2 h, EK(2h))}，其中包含叶节点及其对应的加密位置（128位或256位整数，其位数大于叶子节点数量 2h）。例如，(leaf1,…,leafB)属于群成员1，而(leafB+1,…,leaf2B)属于群成员2，依此类推。随后，管理员根据这些元组的第二个分量按升序对 S中的元素进行排序。新的顺序代表了打乱的树中叶节点的新位置。第一层节点的构建不仅将叶节点包含在哈希中，还包含相应叶节点的加密值，例如hi, j = H(leafi, EK(i)||leafj, EK(j))。从该层到根节点的所有其他树层级仍按常规方式构建，不再做其他修改。由于这一改变，加密索引是认证路径的一部分，因此群管理员可以在发生不当行为时打开签名。在安全性方面，攻击者仅能看到被加密的索引，这些索引以某种方式映射到初始位置（甚至不知道索引‐密文对）。在最坏情况下，分组密码的安全性降低不会超过log2h 比特。

4.3 我们的构造：（有状态）G‐Merkle

在本节中，我们将我们的群签名方案应用于任意基于Merkle树的签名方案。然而，为了保持我们的构造尽可能通用，我们不限定于任何特定的一次性签名方案。下文中，令S=(密钥生成,签名, Verify) 表示在常规Merkle树签名方案中应用的一组算法。

G.KGen(1k, 1N)： 群管理员生成主密钥gmsk ∈{0, 1}k，并初始化一个分组密码(Egmsk(·) Dgmsk(·))。每个用户 i ∈[N]被分配一个与安全的一次性签名方案（例如用于 B（如 B= 2t）个叶节点的Winternitz）相关联的随机私钥 gski。也就是说，群管理员像在常规的Merkle树签名方案中一样调用 N次 G.KGen，但仅输出私钥gski 和作为叶节点的哈希化公钥。群管理员按以下步骤进行： 与所有用户的叶节点相关联的索引集合被打乱

Shuffle(1,..., N · B)=(j1,..., jN·B)

其中 js= Egmsk(s)对于 s ∈[N · B]。例如，叶节点1被放置在树中的位置 j1（见图4）。

随后，群管理员在洗牌后的节点集合上构建G‐Merkle树，并生成群公钥gpk，该公钥表示为G‐Merkle树的根节点。

3. 最后，群管理员将置换后的索引集合转移给用户 i

Si={j(i−1)B+1,..., ji·B}

与用户的叶节点相关联。至于认证路径，群管理员可以选择多种方式来计算签名的认证路径。详见第6节概述。

G.Sign(gski, m)： 用户 i维护一个计数器 t和一个元组列表

state={((i −1)B+ 1, Egmsk((i −1)B+ 1),...,(i · B, Egmsk(i · B))}

定义签名过程中可能的状态。每当用户希望对消息进行签名时，他将获取当前状态

state[t]=[(i −1)B+ t, E gmsk((i −1)B+ t)]

从列表和集合 t:= t+ 1中，第一个分量用于通过其关联的私钥在内部标识节点，第二个分量用于定义叶节点在G‐Merkle树中的位置，以便推导出相应的认证路径。假设第 j个叶节点已被用于签名，则认证路径由节点(a0,…, ah−1),组成，其中 h为树高。定义 := j/2h ，并用 vj[k]表示第 j层的第 k个节点，则我们有

aj={vj[ −1] for  ≡ 1 mod 2 vj[+ 1] for  ≡ 0 mod 2.

最后，通过使用私钥gski ，签名算法输出一个针对消息 m的群签名（σ, m），该群签名由底层签名算法Sign生成的一次性签名以及认证路径（见第6节）组成。

G.Verify(σ,m,gpk)： 确定性群验证算法在G‐Merkle树上调用底层签名方案的 Verify，输入为群签名 σ、消息 m以及G‐Merkle树的根节点。

G.Open(gmsk σ,m): 输入包含确切认证路径的签名时，该路径可由叶节点的位置和中间节点表示，管理员提取位置 l 并对 l ∈[N · B]调用解密算法 Dgmsk(l) = j，否则输出 ⊥ 并终止。随后，他确定集合 Si 使得 |Si| = B 满足 j ∈ Si，并输出 i。

可能的修改。 我们注意到，在实际中很少找到输出大小较小的伪随机置换。在这种情况下，可以采用第4.2节中提出的简单修改方法，使用任意安全分组密码。我们还注意到，在密钥生成阶段可以采用一种动态方法，其中群成员 individually 生成其私钥和关联的叶节点。随后，这些叶节点被提交给群管理员，群管理员对叶节点进行打乱，并在此混合集合上构建Merkle树。这种策略可防止群管理员获知私钥，从而最小化攻击私钥的风险。

5 安全性

在本节中，我们证明第4节提出的构造遵循[CG05]提供匿名性，并根据[BWM03]实现完全可追溯性。该方案的不可伪造性直接来源于其底层签名方案。

5.1 匿名性

对于匿名性，我们证明定义1的一个变体，其中允许攻击者访问被攻破群成员的私钥。攻击者必须猜测签名是在哪个诚实身份下生成的。根据攻击者在选择 阶段是否被允许访问打开预言机的情况，我们要求底层分组密码为SPRP或 PRP。

定理2. 设 N · B为G-Merkle树中的叶子节点数量， N为用户数量。那么，在假设使用强伪随机置换来打乱叶节点的前提下，第4.3节中描述的构造方案遵循定义1中的实验，提供SPRP-匿名性。

证明。 该定理的证明非常简单，因为此时攻击者相当于参与了一个不可区分性游戏的强伪随机置换（SPRP）攻击者，但无法访问加密预言机。也就是说，假设存在一个能够破坏该方案匿名性的攻击者，则我们可以构造一个算法，用于区分在强伪随机置换下生成的不同明文的加密结果。具体而言，在选择阶段，攻击者最初可以访问签名预言机和打开预言机，这实际上相当于可以在其选择的群签名上调用解密算法。由于受限的树大小，对于每个诚实用户，攻击者最多只能查询 B−1 次签名预言机（从而也最多查询打开预言机 B−1 次），以确保每个用户仍有能力生成最后一次签名。此外，攻击者还可以任意腐蚀群成员。最终，攻击者输出某些状态信息st、一条待签名的任意消息 m，以及两个未被腐蚀的现有身份i0, i1。在第二阶段，攻击者接收到状态信息st以及一条对 m 的签名 σ，该签名对应的身份是从 i0 和 i1中均匀随机选取的。此时，攻击者面临的挑战是正确猜测用于对消息 m 进行签名的身份。在此阶段，攻击者仍然可以访问除 σ之外的其他签名上的签名预言机和打开预言机。要求每个用户仍能进行一次签名的条件，防止了攻击者耗尽所有叶节点，并通过尚未向打开预言机查询的剩余签名进行排除法做出平凡猜测。

群签名中唯一依赖于身份的元素是G‐Merkle树中叶节点的位置。所有其他元素都可以被替换为与身份无关的相应分布。根据第4.3节中我们的构造，签名者Sk所拥有的叶节点的索引集为{k0,…, kB−1}= Egmsk({(k−1) · B,…, k· B −1})。我们可以安全地假设，每个诚实身份除了一对明文‐密文对外，其余均已泄露（每个签名者仍可签署最后一条消息），因此剩余的明文 p0 ∈[N · B]和 p1 ∈[N · B]分别对应于 i0和 i1，且这些明文已被攻击者知晓。挑战者的输出是一个随机密文 c，该密文可能加密的是 p0或 p1。在密码算法的强伪随机置换假设下，我们可以将密文集合，特别是 c也一并替换为与明文无关的随机元素与身份相关的索引。因此，该结论成立。我们注意到，如果使用完美的置换来加密索引，那么对于挑战者给出的任何密文，其对应特定明文的概率是相等的。

如果在定义2的实验中，攻击者无法访问打开预言机，则我们甚至可以仅通过使用伪随机置换来证明PRP‐匿名性（类似于定理2）。

定理3。 设 N · B为G-Merkle树中的叶节点数量， N为用户数量。那么，第4.3节中描述的构造满足定义2中实验所规定的PRP-匿名性，前提是使用伪随机置换对叶节点进行打乱。

5.2 可追溯性

完全可追溯性包含了一组其他性质，如[BWM03]中所述。根据图3中给出的可追溯性实验，该证明依赖于底层签名方案的不可伪造性。事实上，我们的G‐Merkle方案直接继承了基本方案的存在不可伪造性，如第2节所述。一般而言，如果基本 Merkle树构造对该类攻击者是安全的，则G‐Merkle树构造也是安全的。因此，若我们的群签名方案G‐MerkleXMSS基于XMSS，则称其为G‐Merkle。

定理4。 设 T为一个基于哈希的一次/少数次签名方案，MerkleT为相应的基于Merkle树的多次签名方案。如果MerkleT在选择消息攻击下具有存在不可伪造性，则群签名方案G-MerkleT也具有存在不可伪造性。

该陈述的证明是直接的，因为多签名者G‐MerkleT方案与单签名者MerkleT方案的区别仅在于洗牌过程中节点顺序的变化以及拥有各自密钥的参与者数量。

定理5 设 T为第4节中定义的G-Merkle中的叶子节点数量。4假设存在一个 PPT可追溯性攻击者，则存在一个算法 B能够破坏底层签名方案的不可伪造性。

证明。 该定理的证明主要基于4所述的底层数字签名方案的存在性不可伪造性。我们证明了除非底层签名方案不安全，否则这样的攻击者不存在。我们通过图3中定义的实验进行，其遵循[BWM03]。

假设存在一个攻击者能够成功生成这样的伪造。显然，在G‐Merkle树构造中，树的高度log2(N · B)和叶子节点数量 N · B是预先已知的，因此只有当用于签名消息的叶节点索引属于{0,…, N · B}时，群签名才是有效的。因此，攻击者必须生成一个对诚实用户身份的伪造 i∈/ C，该伪造签名能够正确通过验证。然而，只有当攻击者破坏了底层签名方案（Merkle树构造）的不可伪造性时，这种情况才会发生，因为他并不拥有与身份 i相关的私钥。根据定理4，这样的攻击者不存在。

6 认证路径计算

G‐Merkle树由来自不同用户的叶节点构成。因此，生成认证路径的传统方法无法直接适用，因为认证路径本身需要知晓其他节点的信息。为此，我们需要采用不同的策略来推导认证路径。接下来，我们提出一些可能的解决方案以实现这一目标。

公共叶节点。 第一种方法类似于最初的Merkle树构造，其中用户存储其关联树的每个叶节点。将此策略应用于多用户环境时，群管理员会发布所有用户的全部叶节点。这导致最多需要 N · B 个节点的存储大小。每当用户调用其签名算法时，它会组合叶节点以生成与其一次性签名相关联的认证路径。或者，也可以发布或存储整棵树，此时内存需求仅增加一倍。在这种情况下，签名的运行时间减少，因为群成员不再需要计算内部节点。

用户导向的认证路径计算。 群管理员还可以在密钥生成期间向每个用户发送认证路径及其相关索引。用户存储这些节点，并可在使用后删除已消耗的节点。

引理1。 设 N表示群成员数量， B表示每个用户的潜在签名数。则用户的内存大小Mem受限于

log N ≤ Mem≤ B · log(N)+ B< N · B

证明。 最佳情况发生在用户的全部节点均为相邻节点时，此时他可以利用自己的密钥对生成认证路径中的多个条目。然而，在这种情况下，他可以构建一个高度为 1+ log2 B的子树，并需要存储log N个节点以构造认证路径。在最坏情况下，用户存储的是第log B层的节点，即B个节点，这使他能够生成 G‐Merkle树上层部分的所有其他节点。这是因为所有 B个可能的签名都必须经过第log B层中的 B个节点之一。此外，他还最多需要存储来自树中其余log N层的 B·log N个节点，这些节点对应于认证路径中的节点。

在实践中，每个用户可以确定要存储的节点的确切数量，从而优化内存大小。他可以消除在多个认证路径中重复出现的节点。例如，所有认证路径都必须使用根节点的左子节点或右子节点。如果用户选择仅存储一次右子节点和左子节点（如需要），则能达到最佳效果。

通过聚类优化存储大小。 基于引理1的证明以及观察到当群成员的叶节点彼此接近时内存大小得以改善，因此可将群组划分为多个簇。该过程由群管理员秘密完成。随后，G‐Merkle树的叶节点也相应地进行聚类。例如，我们将叶节点划分为 k个簇，每个簇包含 N/k个用户的全部节点。这提高了每个群成员多次使用认证路径中某些节点的概率，从而减少了总体存储需求。由于验证者和群成员自身均不知道叶节点如何划分、存在多少个簇以及特定簇内包含哪些群成员，因此在匿名性游戏中若攻击者无法访问打开预言机，则匿名性仍然得到保障。当 N非常大时，这种聚类策略具有优势。聚类策略的另一个优势在于可以使用输出大小较小的分组密码。实际上，输出大小可设置为等于簇大小。

如果攻击者能够访问打开预言机，则该攻击者最多只能得知哪些用户属于同一个簇。这将整个群成员集合中的匿名性降低为较小簇内的匿名性。但在挑战阶段，攻击者无法将某个签名映射到簇中的特定群成员。假设 N= 2t1且簇大小为 k= 2t2，则来自同一簇的用户的认证路径在认证路径中最后log(N · B) −log(N · B/k) = t2个节点始终相同。这是因为特定簇在高度log(N · B/k)处具有相同的父节点，此后其兄弟节点也完全相同。

交互式认证路径计算。 在群管理员维护群签名者私钥列表的情况下，可以以在线方式向群管理员请求所需的认证路径。一旦群成员将其签名部分（一次性签名）连同叶位置发送给验证者，验证者即可向群管理员请求对应的认证路径。显然，这不会影响安全性，因为所有叶节点均可公开。

7 实现

在本节中，我们讨论了方案的实现方面。此讨论基于我们用C语言实现的 G‐Merkle，它是一个扩展按照[HBGM18],中规定的 XMSS/WOTS 实现，使用 SHA2‐256 作为哈希函数。

我们的实现遵循第4.2节中描述的方法，其中使用输出更大的分组密码。具体而言，我们使用AES‐256进行索引加密（该过程充当叶节点的洗牌过程）。因此，叶节点索引最初表示为256位长的整数（左侧用零填充），然后使用 AES‐256进行加密。生成的256位密文被视为新的（打乱后的）叶节点索引。注意，大多数加密索引很可能超出范围[0, 2h −1],但（如第4.2节所述） G‐Merkle仅关心这些加密索引出现的顺序。这些加密索引还用于打开签名。一旦计算出加密索引，它们将按升序排序。我们的实现在对非常大的（256位长）数字排序时采用了简单的快速排序实现。我们注意到，通过使用其他排序算法（例如基数排序）可能在此步骤中获得加速。

表1展示了G‐Merkle内部流程的性能数据。我们将 N= 64固定为群成员数量（也称为用户数量），以便比较不同的树高（但根据群成员数量与签名次数之间的权衡，也可选择其他值）。性能数据以千周期为单位，测量环境为 Intel(R) Core(TM) i5‐63000 CPU @2.40 GHz，配备16GB内存。代码使用 GCC 6.4.0编译，并启用‐O3编译选项。每个过程重复执行100次，取平均周期数。第一列表示G‐Merkle中的相关操作，即叶节点的生成（每个用户都需执行此步骤，即生成所有一次性签名密钥对及其对应的叶节点）、所有索引的加密和排序、Merkle树构建过程、XMSS签名生成、XMSS签名验证以及签名开启（包含一次AES‐256解密调用）。括号内标明该操作是由每个用户（U）执行还是仅由群管理员（GM）执行。其中最耗时的操作是Merkle树的构建，该操作仅由群管理员处理，不会影响用户。

进程（所有者）	N= 64 (h= 14, B= 256)	N= 64 (h= 16, B= 1024)	N= 64 (h= 18, B= 4096)
生成叶节点 (U)	2, 319, 508	9, 302, 171	35, 646, 646
加密索引（GM）	56, 960	225, 818	934, 001
排序（GM）	16, 866	85, 767	364, 334
XMSS树构建（GM）	7,052	114, 011,307	440, 567, 352
XMSS签名（U）	9, 007	7, 153	7,059
XMSS验证（U）	100	9,092	9,398
签名打开（GM）	99	102

实际的群组管理操作，例如叶节点索引的加密和排序以及签名的打开，并不会带来显著的开销，而XMSS算法（签名和Verify）是高效的。我们的实现在第6节中讨论过，假设Merkle树是公开且安全可用的，因此认证路径计算（ XMSS中相对耗时的操作）在此并不相关。

8 结论与讨论

我们提出了首个（有状态的）基于哈希的群签名方案，并证明了它仅依赖于标准假设，而不像其他群签名方案那样依赖昂贵的非交互式零知识证明系统。我们的方法普遍利用了Merkle树的结构。正因如此，我们在运行时间、签名和密钥大小方面能够更高效地生成群签名。值得一提的是，认证路径的提供具有挑战性。通过合并不同用户的多个树并对树结构进行随机化，虽然提升了匿名性，但却失去了XMSS中生成认证路径的简洁性。我们提出了几种获取认证路径的方法（例如发布整棵Merkle树），但强调如何最优地解决这一问题仍然是一个开放性问题。此外，我们强烈强调，完全匿名性将导出一个安全的公钥加密方案。为了说明一旦实现完全匿名性后如何将群签名方案转化为加密方案，群管理员首先生成主密钥以及各个“身份”的所有私钥。群管理员将这些私钥作为公钥公开，而主密钥则保密。当某一方希望加密一条消息时，他将该消息编码为某个身份（或多个身份）的形式，并发送签名给群管理员，后者通过打开签名为密文解密，并揭示代表已编码消息的身份。由于具备完全匿名性，攻击者即使拥有所有身份的私钥也无法揭示该身份。这一结果在密码学领域将产生巨大影响，因为它将允许仅基于单向函数的存在性来构建公钥密码学。然而，这在某种程度上与[IR89],所指出的结果相矛盾，即单向函数不足以构建密钥协商协议。