BB-RO 方案 在随机谕言机模型下的安全证明

本文探讨了BB-RO方案在随机谕言机模型下的安全证明,详细解析了其系统初始化、秘钥生成、签名及验证阶段。通过设计合理安全规约算法,证明了在CDH假设困难的情况下,BB-RO协议在EU-CMA模型下是可证明安全的。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

BB-RO 方案 在随机谕言机模型下的安全证明

密码学可证明安全推荐书目(系列博客内容为这两本书学习笔记与内容小结):

《密码学中的可证明安全性》杨波 清华大学出版社

《Introduction to Security Reduction》Fuchun Guo;Willy Susilo;Yi Mu Springer

BB_RO 方案描述

系统初始化阶段:

                           

         系统初始化阶段与BLS 协议相同。

秘钥生成阶段:

                             

         秘钥生成阶段,私钥为整数群上选取的一个随机数,公钥为一个二元组(g1,g2)其中g2 是群上的一个随机生成元素。

签名阶段:

                               

         签名阶段,签名分为两个部分,第一个部分,为使用私钥对签名的哈希值进行签名。第二部分,为岁随机数r的运算,此处可以看做是对随机数r的隐藏。

验证阶段:

                             

安全证明:

定理 : 如果BBRO协议中的哈希函数是随机谕言机,并且CDH假设是困难的,那么BBRO协议在EU-CMA模型下是可证明安全的,规约损失 L= qH,其中qH 为哈希询问的次数。

要证明这个定理,实质上就需要设计一个合理的安全规约算法,其中设置模拟者给与敌手的签名是可模拟的,敌手伪造的签名是可规约的。而实现这个功能的途径就是将随机谕言机,通过对随机谕言机进行编程,是的敌手获得的哈希询问结果只能计算出可规约签名,模拟者查询哈希询问结果并且计算得到的签名只能计算出可模拟签名。

一般来说,常用的随机谕言机编程如下:

                                                                     

对于CDH假设下的数字签名,这个范式比较常用,已知 g,g^a,g^b,求g^ab。

x 可以控制b的存在与否,y 是随机值,为了保证随机谕言机每次返回的值都是独立随机的。

                                  

将公钥,设置为CDH的前置条件,a 为私钥。敌手不知道私钥,给与敌手一个CDH问题实例。

                                 

                                 

敌手请求哈希询问,模拟者构建一个哈希列表,并且设定第i次敌手请求的消息是mi, 也就是说,模拟者提前猜测敌手会在这一次发动伪造签名攻击。根据敌手询问的次数,分别设计随机谕言机给与敌手的回复。注意,第i次请求敌手将会产生可规约签名,其他情况下,模拟者输出可模拟签名,敌手不能分辨是可模拟的还是真实签名。

                                   

签名询问,如果敌手询问第i次签名,则模拟者中断,因为不允许敌手询问伪造签名的消息。模拟者随机选择一个r`,然后反向表示r` ,得到算法形式上的随机数r。与之前说到的签名不同,这个设计就比较复杂了。最后得到可模拟的签名。

                                    

伪造签名,当敌手选择第i次的消息M*做完哈希询问后,随机伪造这个消息的签名,得到一个可规约的签名。

敌手的优势为1\qh *adv , 证明完毕。

一个思考:

如何构建规约?从现在来看,其实安全规约就是在凑参数,通过精心设计规约算法的参数,构建一种闭环、自洽的证明逻辑。在Guo Fuchun 的书中,他简单的将随机谕言机下安全规约做了三个分类 分别是H型 I型 C型。那么,为什么要分成这几种类型呢?这几种类型应该是比较常见的,但是在实际设计安全规约的过程中,必须根据实际情况来选择参数的变化,例如 H型 和 I型的区别就是公钥中包含的困难问题条件信息不同,在设计安全规约时的参数考量就会不同。

### 随机与标准模型的区别 随机(Random Oracle, RO)和标准模型代表了两种不同的理论框架,在密码学分析中用于评估加密方案安全性。 #### 安全证明环境差异 在随机模型下,哈希函数被理想化为一个随机选择的函数,即每次输入都会得到不可预测且唯一的输出。这种假设简化了许多复杂问题的处理过程[^1]。然而,在标准模型中,所有的组件都必须基于已知的实际构建模块,不允许引入理想的黑盒组件如随机。这意味着在标准模型里验证的安全性更加贴近真实世界的情况,因为这里使用的都是具体的、可实现的技术手段而非抽象的理想对象。 #### 应用场景对比 - **随机模型** 此模型允许研究人员更容易地设计并论证某些类型的协议特别是那些依赖于强假定条件下的高效解决方案的有效性和安全性。例如,在BLS签名方案及其改进版本的研究过程中发现,当采用随机时能够提供较为简洁明了的安全证明路径[^2][^3]。不过值得注意的是,虽然这种方法有助于快速建立初步信任度,但由于它所依据的前提过于理想化,因此难以直接转换到实践中去。 - **标准模型** 对比之下,如果能够在不借助额外理想化的条件下完成同样的任务,则意味着该成果具备更强的实际操作价值。对于追求更高层次保障级别的应用场景而,确保算法能在没有任何特殊假设的情况下保持稳健是非常重要的。比如,在涉及长期存储数据保护或者跨平台互操作性的场合,倾向于优先考虑经过严格检验的标准模型下的构造。 ```python def hash_function(input_data): """模拟标准模型中的实际哈希函数""" import hashlib sha_256 = hashlib.sha256() sha_256.update(input_data.encode('utf-8')) return sha_256.hexdigest() print(hash_function("example")) ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值