利用密码学和计算机视觉进行用户界面验证与高效算术扩展
在软件或界面验证等场景中,临时方法虽能提供一定支持,但正式概念在实践中部署颇具挑战。本文将探讨一些正式概念,并研究现代机器学习如何助力实现更好的用户界面(UI)保障,同时对一种流行的非交互零知识证明(NIZK)方案进行算术扩展。
从GUI渲染合成后端通信
典型的用户界面通过前端客户端根据后端服务提供的基于JSON文本的字典树模型
x
更新展示内容,客户端GUI
G
渲染出图像
G(x)
。为证明对输入
x
的感知,需从
G(x)
中提取
x
,即从后端“明文”JSON的角度解释GUI。
-
定义1
:对于模型数据的输入分布
D
,若存在高效解释器
I
,使得
I(G(x)) = x
的概率超过
1 - ϵ
,则称GUI
G
对模型具有
ϵ
- 感知。
-
定义2
:考虑到GUI可能有意省略信息,引入过滤器
F
限制对模型数据子集的要求。对于模型数据的输入分布
D
,若存在高效解释器
I
,使得
F(I(G(x))) = F(x)
的概率超过
1 - ϵ
,则称GUI
G
相对于过滤器
F
对模型具有
ϵ
- 感知。
-
定义3
:设测试套件
S
以分布
D
生成后端文本模型,若GUI
G
相对于分布
D
和过滤器
F
对模型具有
ϵ
- 感知,则称其满足基于感知的保障。
我们希望考虑验证器,证明它们无法区分真实和理想情况,目标是提供一个简单的验证器用于测试驱动开发。
基于感知的开发范式
将密码学感知与用户界面开发进行类比,目的是通过促进测试驱动开发(TDD)使UI更健壮。新范式如下:
1. 使用高质量幻灯片(如PowerPoint)进行可视化规范。
2. 定义后端模型(JSON模式)。
3. 在标注的规范(设计文档)上训练对象检测器以识别可操作元素。
4. 编写测试代码将检测到的可操作元素映射到合成的JSON。
计算机视觉在该范式中是关键元素,它通过用强大的自动化测试框架取代当前昂贵且脆弱的验证模式,实现UI的可视化测试自动化。案例研究表明,基于计算机视觉的对象检测可从高质量设计规范中训练,并稳健地应用于实际实现的GUI,减少了人工质量保证(QA)的工作量,消除了黄金快照的脆弱性。
在基于感知的测试驱动开发阶段,不仅要检测可操作元素,还要通过重现生成它们的原始JSON来正式验证图像。例如,在测试屏幕上是否显示紧急指示器时,编写提取器代码将检测到指示器的状态映射到触发指示器的JSON子树,当未检测到指示器时生成不包含触发条件的JSON。
简单案例研究显示,使用自动化基于感知的验证进行测试驱动的GUI开发是可行的,且耗时不到一周。在一个简单案例中,过滤JSON的警告模式并使用伪随机生成警告状态的测试套件,提取的JSON与实际源JSON完全匹配。
在线自我验证
解释器/提取器在测试设置中应高效运行,即使在资源有限的客户端硬件(如手持设备)上,对象检测处理速度也足够快,可实时检测提取的JSON与后端提供的JSON之间的不一致。通过在应用程序中部署自我测试,基于感知的验证能提供更强大的保障,因为它依赖于准确的真实世界分布,而非开发期间使用的合成或采样日志。
总结
本文描述的UI验证范式依赖于对展示图像的廉价自动化解释,而非传统的脆弱图像一致性检查或昂贵的人工图像解释。该范式的两个关键要素是:近期计算机视觉技术(如对象检测)的强大能力,以及受密码学明文感知启发的概念,用于定义和衡量解释目标——后端提供的模型数据。通过自动化基于后端模型数据的UI解释,基于感知的测试驱动范式可在项目首次实现之前设置测试,降低测试成本,提高测试的吸引力和稳健性,从而增强部署期间的保障。
KKW方案的高效通用算术扩展
Katz等人在2018年提出的KKW方案是一种流行且高效的MPC - in - the - Head非交互零知识证明(NIZK)方案,是后量子签名方案Picnic的技术核心。该方案在商用硬件上具体高效,无需可信设置,且在证明生成时间、验证时间、证明大小和内存消耗方面与电路大小呈线性缩放。然而,KKW仅适用于布尔电路,对于包含算术运算的电路成本较高。
动机与背景
零知识证明(ZKPoKs)允许证明者在给定公共电路
C
的情况下,证明其持有见证
w
使得
C(w) = 1
。非交互零知识证明(NIZK)可在不与证明者交互的情况下传输和验证。近年来,多数相关研究优先考虑小证明大小和快速验证,但这往往导致证明者成本显著增加,且证明时间通常与证明电路大小呈超线性关系。
对于在移动设备等资源有限的环境中运行ZK证明者的应用,适度的资源要求(如低内存使用)至关重要。KKW方案在通信、证明者计算和验证者计算方面呈线性缩放,内存消耗低,使用轻量级计算原语,无需可信设置,且受社区积极支持,但仅支持布尔电路。因此,本文旨在通过扩展高效算术运算和布尔与算术表示之间的转换来改进KKW方案。
平衡ZK证明的用例
考虑一组通过本地Wi - Fi或蓝牙广播网络连接的移动电话,如在群组活动或私人接触追踪场景中。若一部手机希望向广播频道上的所有人证明一个陈述,交互式指定验证者系统需为每个验证者重复证明,而NIZK证明可广播,是更好的解决方案。在这种设置下,广播网络资源相当可观,完成证明(包括生成、传输和验证)的瓶颈通常是证明生成/验证,因此KKW方案因其在证明大小上的高效线性缩放而成为首选。
贡献与工作概述
我们为KKW方案扩展了高效的环算术运算和布尔与算术表示之间的转换:
- 提出与KKW一致的合适环表示。
- 构建高效的转换运算符,实现算术和布尔表示之间的转换。
- 展示如何在算术表示上高效操作,例如计算长度为
n
的向量点积,成本仅相当于一次乘法。
这些改进显著提升了包含算术运算的电路的KKW方案性能。例如,使用扩展后的方案,将100×100的32位数字方阵相乘时,证明大小比标准KKW方案小3200倍(点积构造带来100倍改进,转向算术表示带来32倍改进)。
我们详细讨论了证明大小和资源消耗,并论证了在商用硬件上运行大型证明的可行性。
以下是基于感知的开发范式流程:
graph LR
A[可视化规范] --> B[定义后端模型]
B --> C[训练对象检测器]
C --> D[编写测试代码]
以下是KKW方案改进前后对比表格:
| 方案 | 适用电路 | 证明大小 | 计算成本 |
| ---- | ---- | ---- | ---- |
| 标准KKW | 布尔电路 | 大 | 高 |
| 扩展后的KKW | 含算术运算电路 | 显著减小 | 降低 |
利用密码学和计算机视觉进行用户界面验证与高效算术扩展
高效算术运算扩展细节
我们对KKW方案的扩展主要聚焦于高效的环算术运算以及布尔与算术表示之间的转换。下面详细介绍这些扩展的具体内容。
向量点积运算
考虑一个有限环,其元素长度为
l
位。我们添加了一个高效的操作来计算两个任意大小的环元素向量的点积,仅需
2l
个证明位。具体步骤如下:
1. 输入两个长度相同的环元素向量
A
和
B
。
2. 对向量
A
和
B
中的对应元素进行逐对相乘。
3. 将所有相乘结果相加,得到点积结果。
4. 生成
2l
个证明位来表示这个点积运算。
这个操作大大降低了向量点积运算在KKW方案中的成本,提高了计算效率。
布尔与算术表示转换
我们还添加了高效的布尔与算术表示之间的转换操作。具体来说,是在布尔值和任意
k
的环
Zk
之间进行转换。设
l = log k
,将
l
个布尔值转换为一个算术值(或反之)的成本为
l^2
位证明。转换步骤如下:
布尔转算术
:
1. 将
l
个布尔值按顺序排列。
2. 根据二进制编码规则,将布尔值序列转换为对应的算术值。
3. 生成
l^2
位证明来表示这个转换过程。
算术转布尔
:
1. 将算术值转换为二进制表示。
2. 将二进制表示拆分为
l
个布尔值。
3. 同样生成
l^2
位证明来表示转换。
这些转换操作使得KKW方案能够更灵活地处理包含算术运算的电路。
安全协议与性能分析
在第6部分,我们将扩展后的方法形式化为一个
p
方半诚实协议,并在预处理模型中证明了其安全性。同时,解释了它如何融入KKW方案的诚实验证者零知识协议。通过Fiat - Shamir变换,我们的方法直接扩展了KKW的NIZK证明系统。
在第7部分,我们详细分析了扩展后系统的性能,包括单个门的成本,并与标准KKW方案进行了比较。结果表明,对于算术运算,我们的方法显著改进了KKW方案。特别是在线性算术方面,我们的改进尤为明显。
以下是扩展后系统的性能对比表格:
| 操作类型 | 标准KKW成本 | 扩展后成本 | 改进倍数 |
| ---- | ---- | ---- | ---- |
| 向量点积 | 高 |
2l
证明位 | 显著 |
| 布尔与算术转换 | 高 |
l^2
位证明 | 显著 |
总结与展望
综上所述,我们通过对用户界面验证和KKW方案的扩展,取得了显著的成果。在用户界面验证方面,基于感知的开发范式和在线自我验证机制提高了UI验证的效率和可靠性,降低了成本。在KKW方案扩展方面,高效的算术运算和转换操作使得该方案能够更好地处理包含算术运算的电路,减小了证明大小,降低了计算成本。
未来,我们可以进一步探索这些技术在更多领域的应用,例如区块链、物联网等。同时,可以继续优化这些方法,提高性能和安全性,以满足不断增长的需求。
以下是KKW方案扩展的整体流程:
graph LR
A[标准KKW方案] --> B[添加向量点积运算]
A --> C[添加布尔与算术转换]
B --> D[形式化安全协议]
C --> D
D --> E[性能分析与优化]
通过以上的扩展和优化,我们为用户界面验证和零知识证明领域提供了更强大、更高效的解决方案。
超级会员免费看

603

被折叠的 条评论
为什么被折叠?



