Loading...
正在加载...
请稍候

雾计算中支持解密外包的可验证属性加密方案

2026-06-01 13:46

🔍 耿同学打假报告

论文信息

  • 标题:雾计算中支持解密外包的可验证属性加密方案
  • 作者:段亚红, 王峥, 赵涓涓, 王龙
  • 期刊:计算机工程与科学
  • DOI:10.3969/j.issn.1007-130X.2023.03.009
  • 发表年份:2023
  • 论文来源:雾计算中支持解密外包的可验证属性加密方案_段亚红.pdf

综合评定:🟠 高度可疑

详细发现

发现 1:第六式 - 算法逻辑缺失(凭空计算的智能合约)

  • 位置:Section 3.3 (3) ⑤ 智能合约验证 & 算法 5
  • 描述:算法 5 声称智能合约可以通过计算 \(\sum c_x C'_x = 0\) 来验证用户的访问权限。然而,检查其输入 Proof={hashCode, hashCode', Address} 发现,并没有包含用户属性集合 \(S\) 或访问矩阵 \(M\)
  • 证据
    1. 输入不足:要计算常数集合 \(\{c_x\}\),必须知道用户的属性集 \(S\) 和密文中的策略矩阵 \(M\)。但 Proof 的输入参数里只有哈希值和地址,智能合约根本无从得知 \(S\)\(M\),步骤 2 “计算常数集合” 在数学上属于无米之炊。
    2. 数据源不明:步骤 3 要求“读取密文中验证访问权限相关部分 \(\{C'_x\}\)”,但智能合约运行在区块链上,通常只存哈希(hashCode)和地址(Address),并不存储完整的密文 CT(考虑到 gas 费和存储成本)。合约如何能“读取”到 \(C'_x\)
  • 严重程度:🔴

发现 2:第六式 - 系统流程自相矛盾(密钥生成的时间穿越)

  • 位置:Section 3.2 系统流程 & Section 3.3 (3) ⑤
  • 描述:论文在系统流程(图2及描述)中将“密钥生成”列为第4阶段,且注释说明“密文正确性确认无误后”才执行。而在 3.3 节的智能合约验证步骤中,更是明确写到:“当 Proof 验证结果为 True 时... 则 CA 生成属性私钥”。
  • 证据
    1. ABE(属性加密)的核心优势在于离线的访问控制,即用户一旦从 CA 获得密钥,就可以自主解密满足策略的密文,无需 CA 介入。
    2. 本文的流程变成了:用户请求下载 -> 雾节点下载密文 -> 区块链验证 -> 通知 CA 生成密钥
    3. 这意味着每次解密都需要 CA 在线参与。如果每次访问都要 CA 实时生成密钥,那这就退化成了基于身份的在线访问控制,完全丧失了 ABE 的意义。这种设计不仅效率低下,而且与“减轻 CA 负担”的云雾计算初衷背道而驰。
  • 严重程度:🔴

发现 3:第六式 - 隐私泄露漏洞(名不副实的属性加密)

  • 位置:Section 3.3 (3) ⑤
  • 描述:基于发现 1 的逻辑漏洞,如果智能合约真的要执行算法 5 进行验证,它必须获取用户的属性集 \(S\) 来构造向量。
  • 证据:在区块链(尤其是公链或联盟链)上执行涉及用户属性 \(S\) 的计算,意味着用户的属性信息必须暴露给区块链节点。这与论文引言中声称的“隐私保护”和 ABE 的基本属性隐藏特性相矛盾。
  • 严重程度:🟠

发现 4:第二式 - 实验数据缺失与理论矛盾

  • 位置:Section 5.2 实验分析 & Figure 3, 4, 5
  • 描述:论文声称进行了实验,给出了图表,但文本中未提供任何具体的数值数据,仅描述了趋势。更关键的是,由于算法逻辑本身存在上述硬伤(智能合约无法执行),实验结果的真实性存疑。
  • 证据
    1. 无法复现:由于算法 5 逻辑不通,任何基于该算法的原型系统都无法正常运行,因此声称的“记录系统运行10次”在逻辑上是不可能的。
    2. 设备信息:使用 AMD Ryzen 5 2500U(2017年末上市)在 2022 年进行实验,设备虽然老旧但物理上可行,然而考虑到算法逻辑的错误,实验数据可能是模拟生成的理论值,而非真实系统运行结果。
  • 严重程度:🟠

发现 5:第一式/第三式 - 图片与排版问题

  • 位置:全文公式 & 摘要
  • 描述:OCR 文本显示公式排版混乱(如 \(K = g^{\alpha+k\alpha b+ka} h^{bc}\) 的格式),且英文摘要存在明显的连字错误(如 "Averifiable", "fogcomputing")。
  • 证据:虽然这可能是 PDF 转文本时的 OCR 错误,但也反映出文章校对的粗糙。结合前述的逻辑硬伤,这种低级错误进一步佐证了文章可能缺乏严谨的打磨。
  • 严重程度:🟡

耿同学辣评

这篇论文就像是把“区块链”、“雾计算”、“外包解密”这几个热词放进搅拌机里打碎,然后加上一点数学公式作为粘合剂拼凑出来的弗兰肯斯坦。
最精彩的地方在于那个“智能合约验证”——不需要用户属性,不需要访问策略,不需要密文,合约就能凭空计算出权限验证结果。这已经不是在写代码了,这是在写科幻小说,建议作者转行去修仙,毕竟“凭空造物”这项技能在学术界也是很稀缺的。

建议后续行动

  • 在 PubPeer 上提出质疑
  • 联系作者要求提供可运行的源代码,验证智能合约部分
  • 向期刊编辑部举报

⚠️ 免责声明

本报告由 AI 辅助生成,仅供学术讨论参考。
学术不端的最终认定需要专业机构调查。
我们支持学术诚信,但也尊重每一位研究者的名誉权。
如有异议,请以官方调查结论为准。
本工具不保证检测结果的准确性,误报和漏报均有可能。