琬点聊丨密码学博士带你了解「零知识证明」与「隐私币」_SUT:ASH

3月26日19:00,「琬点聊」第二十五期开播,本期主题为「密码学博士带你了解零知识证明与隐私币」,本次直播由BlocklikeCEO小琬对话上海交通大学密码学博士、SuterusuCTO林煌。

林煌博士:SuterusuCTO,拥有上海交通大学的密码学博士和佛罗里达大学的隐私保护分布式系统博士学位。曾在洛桑理工学院担任博士后研究员,负责基因组数据保护和基于区块链的数据货币化方面的应用密码学研究。后任香港应用科技研究院副主任工程师,是若干区块链项目的PI,负责架构及方案设计。曾在多个顶级IEEE期刊和密码安全会议上发表二十几篇论文,引用次数过1000。

本次直播中,林煌带我们进入了密码学的世界,深入浅出地科普了关于隐私保护,零知识证明的原理,隐私币的种类差异等等问题。

以下为本期直播内容,由Blocklike编辑整理:

小琬:近期主流社交媒体微博被爆出泄露用户大量隐私,「有5.38亿条微博用户信息在暗网出售,其中,1.72亿条有账户基本信息。涉及到的账号信息包括用户ID、账号发布的微博数、粉丝数、关注数、性别、地理位置等」,此事在社会上引起了热议。作为隐私保护方面的专家,您认为目前社会中存在的隐私泄露事件都是由哪些原因引起的?隐私泄露都有哪些路径呢?

林煌:导致隐私泄漏的原因可以从两个角度分析:一个是系统在设计实现时存在的漏洞,另外是用户在实际使用过程中的疏忽。

比如这次微博隐私信息泄漏事件,我了解的情况是微博的访问控制系统允许用户使用本地手机通信录来搜寻朋友手机号所使用的账号。这个看似合理的访问控制机制允许黑客利用这个漏洞,通过伪造本地手机通信录来扫描账户所使用的手机号。这个算是系统设计时的疏忽导致的攻击。

Bybit宣布集成ChatGPT:金色财经报道,加密货币交易所ByBit将寻求利用人工智能 (?AI?) 通过与ChatGPT的集成为用户提供大量新的交易工具和指标。ByBit的ToolsGPT将ChatGPT的机器学习技术与交易所的市场数据相结合,提供技术分析、价格数据和指标。该集成还允许ToolsGPT为交易者的查询生成定制的答案。[2023/6/15 21:39:59]

另外一些实现方面的漏洞,比如很多安全系统用到密码算法,而密码算法的实现是很容易出问题,如前段时间轰动一时的针对openssl实现的heartbleed攻击,还有针对各种系统漏洞的零日攻击等等。

在实际使用中也容易出现各种问题,比如用户在选择系统密码时可能会选择一些随机性极弱的密码,如123456等,这个黑客很容易就能猜出来,还有用户为了记忆方便,可能在多个网站上使用相同的密码,这也很容易导致黑客通过撞库猜出对应的密码。

这些看起来似乎是个很常见很容易解决的问题,但在实际中确实屡见不鲜,甚至国家级的安全部门都会犯这种低级的错误,比如最近CIA的一个用于网络攻击的工具库的泄漏也是由于管理员设置的密码过于简单,结果被人成功攻击了。

据报道,他们设置的密码分别为123ABCdef和mysweetsummer,所以哪怕这些理应非常专业的部门也会犯这种非常低级的错误。

另外很多时候黑客会使用各种malware来攻击,比如给用户发些附有malware链接的钓鱼邮件等等,很多时候这种社会工程学的攻击往往会利用一些人性的弱点,所以需要用户随时保持警惕才能防止这种攻击。

小琬:允许使用本地手机通信录来搜寻朋友手机号应该是社交平台必备的功能,是否都会存在比较大的信息泄露风险?毕竟连微博实力这么强的平台都会有漏洞,更别提小软件了。

林煌:是的,所以很多时候系统设计时可能需要在系统的可用性和安全性之间做取舍。安全本质上是取舍的艺术。

小琬:隐私的重要性不言而喻,对于大数据时代习惯了使用互联网生产和生活的个人及组织更是如此,然而目前的现状却是大众苦隐私泄露久矣却多束手无策,在您看来,我们可以通过哪些门槛较低的方法来保护个人及组织的隐私?如果隐私已经泄露出去了,可以有哪些方法来及时止损呢?

林煌:我觉得首先要防患于未然,也就是在系统设计实现这个阶段要有专业人士参与,尤其是像密码方案的设计和实现有很多需要注意的地方,比如要使用在实际中被反复测试过的密码代码库等。

这也是为何我们强调应该多支持密码代码库的设计和实现,包括像Suterusu这种项目,因为安全可靠的密码代码库需要出色的密码学家和工程师通力合作,这需要有足够的资源长期地支持才可能完成。

另外,从用户的角度讲,要提高安全意识,养成良好的上网习惯,如果你嫌设置随机性高的密码使用起来过于麻烦,也可以用一些密码管理器。当隐私信息泄漏时,比如微博上的账户密码泄漏,应该及时地重置相关隐私信息。

小琬:其实大家都会有意识的保护隐私,但有时候防不胜防。比如密码的管理,安全和容易记忆也需要取舍。我也尝试用过密码管理器,不过比较担心密码管理器的安全。林博士觉得密码管理器是否安全,有没有推荐的比较安全的密码管理器。

林煌:其实还是有些简单易用的密码生成和记忆法的,也不一定非得用密码管理器。我不使用密码管理器的,可以给你推荐一种manuelblum,一个图灵奖获得者设计的一种随机密码生成法。这个基本思想是,你自己设计一个数学算法,将字母和数字对应。然后每次你用一个网站,你可以用该网站网址使用这个算法和数字对应,当然生成的密码随机性不一定足够强,不过如果你的算法本身不泄漏的话,在实际中应该是够用的。

小琬:主打隐私保护的隐私币作为一种特殊的币种,在行业中热度很高,您作为密码学博士,是如何看待隐私币的呢?不同的隐私币有哪些区别?

林煌:首先隐私币是一个将理论密码学应用于实际的非常棒的社会实验。由于这些尝试,零知识证明等非常艰深的密码学概念才得以走出实验室,为大众所知。目前主流用到零知识证明的隐私币主要包括zcash,门罗币以及稍微小众点的grin和beam。

zcash所使用的零知识证明需要可信初始化,他允许攻击者在无法被侦测到的情况下打印无限量的zcash,而门罗币目前使用的环签名方案虽然不需要可信初始化,但签名大小还是和匿名集合线性相关,相对而言又不是那么scalable。

grin和beam都是mimblewimble协议的实现,由于mimblewimble协议本身是在匿名性和scalability之间找tradeoff的方案,所以在隐私性上相对弱一些。另外上述几种隐私币几乎都不支持智能合约。

我们Suterusu项目提出的匿名支付方案允许我们的隐私保护区块链协议在安全性和可扩展性之间获得最佳均衡,即几乎常数级别的证明大小且无需可信初始化。我们的匿名支付方案还支持智能合约平台,因此能支持些更为复杂的金融科技方面的应用。

如果大家有兴趣了解更多关于隐私币方面的区别,可以参考下我之前写过的两篇相关的文章:杂谈去中心化隐私支付和介绍zcash和mimblewimble的文章。

小琬:这里可能还需要您解释一个概念:可信初始化。

林煌:所谓的可信初始化是由于这种类型的零知识证明协议的初始化过程中涉及一些陷门知识,这种陷门知识好比数字签名方案中的私钥。在签名方案中你的私钥泄漏给攻击者,那攻击者可以生成合法的签名而不被探测。在零知识证明方案中这种陷门知识泄漏则允许攻击者生成合法的证明而不被探测。由于在实际中需要一个entity负责初始化过程,这种陷门知识必然为这个负责的entity所掌握,因此实际上这和去中心化支付的理念是背道而驰的,而且也是个巨大的安全隐患。尽管zcash试图使用安全多方计算来解决这个问题,但安全多方计算还是有可能引入新的安全漏洞,而且攻击者还是有可能成功攻击这些多方计算的参与者,所以这不是彻底的解决方案,理想的零知识证明方案应该是无需可信初始化的。

小琬:零知识证明被认为是保护数据隐私的一种优质方案,但其作为一种新型的科学技术,尚难以被大众理解。作为零知识证明领域的前沿探索者,请您为大家深入浅出地讲解一下零知识证明的原理。

林煌:零知识证明其实可以看作一种加密的数学证明。当你读完一个数学证明,正常情况下你应该有种在数学上功力见长的感觉,因为你掌握关于这个定理的新知识。

而零知识证明则有所不同,他的目的不在于让证明验证者掌握新知识,他的核心目的是说服验证者证明者懂得如何证明这个命题,或者更正式地说他掌握了使得命题成立所需的秘密,仅此而已。

他不关心验证者读完证明后有没有掌握新知识,事实上这里的零知识恰恰被定义成证明本身除了泄露一个事实:即证明者掌握了使得命题成立需要的秘密外,不泄漏其他任何信息。

所以零知识证明的证明往往是以密文的形式出现,所谓密文你可以把他看作一堆乱码。换句话说通过读这些乱码,就能相信命题成立,相信证明者懂得如何写这个证明,但除此之外你一无所知。

由于零知识证明本身是以乱码的形式出现,这时候我们就得考虑一个问题,就是如果一个没有掌握证明这个命题所需秘密的人,一个攻击者浑水摸鱼滥竽充数怎么办?

所以零知识证明的另外一个性质可靠性就变了非常有意义,他的目的就在于保证攻击者在不掌握证明命题成立所需的知识或秘密情况下是无法伪造证明的。

当然,零知识证明还得考虑完整性这个性质,我们这里暂时就不展开了。

通俗地说,零知识证明可以看作数字签名和加密两种概念的推广和结合。零知识这个性质其实和加密方案所需的保密性有一定对应关系的,加密方案的保密性能保证加密密文不泄漏所加密明文的任何有用信息。零知识这个性质在隐私币中则通常用于保证隐私性。

而可靠性则可以看作数字签名方案的不可伪造性在通用命题中的一种推广。在数字签名方案中,一个没有签名密钥的用户是无法伪造签名的,这就是所谓的不可伪造性。零知识证明的可靠性在隐私币中往往用于保证只有用户掌握隐私币对应的秘密情况下才能成功花掉相应货币。

小琬:中本聪在其短短9页的比特币白皮书中用了一整个章节讨论比特币的隐私问题,数字货币自诞生以来,围绕着其产生的隐私安全问题就一直备受行业从业者的关注,请问在您看来零知识证明可以为数字货币的隐私安全提供哪些助力?

林煌:零知识证明在保密支付中最简单的应用就是用于证明当输入和输出金额以密文或数字承诺的形式出现时满足balance的条件,即输入金额之和等于输出金额之和。由于密码方案通常在有限域上进行,因此一个负数等价于一个很大的正数,往往需要使用区间证明来证明金额在合理的范围之内。

为了保证交易参与者的隐私,会使用到成员证明来隐藏交易发起者身份。另外,如果发送者需要给接受者加密一些信息,可能会使用零知识证明证明所加密内容的合法性。这些都是零知识证明在数字货币交易隐私方面所起的作用。

近来,零知识证明在personaldatamonetization方面也出现了不错的应用,比如basicattentiontoken项目最近使用零知识证明在保证用户隐私的同时区分获得token的是真正的用户而非僵尸网络,详情请查我之前写的介绍这个zk-sense项目的文章。这个既和basicattentiontoken这个数字货币有关,又和传统互联网经济的新模式相关,非常有意思。

另外,如果考虑数字货币的应用基础设施的话,比如半去中心化的身份认证设施或者联盟身份认证设施,由于涉及用户身份隐私和可问责性,零知识证明也有用武之地。

小琬:着重于隐私、分权及可扩展性的门罗币是最早的也是最热门的隐私币种之一,有非常多的用户持有并且使用它,请问您对门罗币的评价是?

林煌:门罗币在社区方面做得很不错,但就像我上面提过的那样,在scalability和效率上其实还有很大的提高空间,另外,门罗币本身是不支持智能合约的。

相比之下,我们Suterusu的方案在安全性上不逊色于门罗币,在scalability上比他们更有优势,且支持智能合约。

小琬:目前全球对于数据与隐私安全间的政策尚不明朗,很多留存在互联网中的隐私正在被当做是免费的数据在使用,有观点认为数据的「隐私」边界不在该不该发现和汇集一些必要的信息,而在于后续,这些信息如何被保存、管理、分析和使用。请问在您看来,数据的监管与「隐私」边界在哪?

林煌:这种观点可能未必准确,我认为保护数据的隐私必须从数据源头做起,我们知道系统的安全程度取决于系统中最弱的一环。而很多时候,数据系统最弱的一环可能就恰恰在数据的源头,目前隐私系统设计的一些新理念包括bringapplicationtodata事实上也和这个前提密切相关的。

近年来隐私数据监管方面的进展是有目共睹的,这包括欧洲的一般数据保护法和美国加州最近公布的消费者隐私法。这些法规对商家monetize用户数据的过程提出了很多要求。

比如CCPA明确指出:用户个人信息如果被用于所知会的不同目的,商家必须提前告知并征得用户同意才行。再比如,商家如果提供金融激励来购买用户隐私数据时,必须明确说明估算用户数据价值的具体方法。

在法规上逐渐明确地定义用户对个人数据的所有权和控制权是件好事,但法规没有技术的配合是行不通的。未来随着个人数据主权的建立以及personaldatamonetization框架的建立我相信密码技术会在这个过程中起到至关重要的作用。

这里可能包括从在多方数据分享时可能用到的多方计算技术,为了保证多方计算过程的计算可靠性会用到的零知识证明技术,比如为了给隐私数据合理定价设计的隐私保护的数据定价技术,甚至可以想象将来由于用户数据对于不同的买家的价值不同而导致价格不同,也许智能合约也可以用于自动化这种monetization过程。

小琬:您在Suterusu担任CTO,这个项目在应用路径上跟其他隐私币的差别在哪里?

林煌:我们设想的Suterusu的应用场景主要有以下几种:匿名交易,关于数字货币的匿名化要求将越来越强,Suterusu作为一个隐私保护二层协议将为其他主流数字货币提供匿名化服务。另外,我们也会考虑提供可控匿名的模块,从而满足用户对合规化方面的要求。由于suter提供了智能合约功能,可以通过智能合约自动化实现合规请求。另外一个应用场景是零知识身份证明,现在一个网站的注册用户登录时几乎都要向网站管理员泄漏自己的身份,通过在身份认证过程中引入零知识成员证明有可能在满足身份认证要求同时还能保护用户隐私。此外,我们也在研究使用零知识证明来提高区块链系统的scalability。目前比如zk-rollup还有coda的思路都是使用零知识证明来提高区块链的scalability,但它们多多少少都存在一些安全隐患。比如帮助生成零知识证明的operator有可能被dos攻击等,所以,这方面也是我们研究努力的方向。

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

金宝趣谈

[0:0ms0-3:630ms