当前位置: 首页 > news >正文

驳斥关于 ML-KEM 的误解

1. 引言

最近,人们对 NIST 的后量子密码加密标准 ML-KEM、IETF 的相关标准产生了一些担忧,还有许多阴谋论声称恶意行为者操纵了标准化流程。作为一个几乎参与了这一标准化流程各个层面的人,Sophie Schmieg 想快速驳斥自己听到的种种无稽之谈。下面就以常见问题的形式开始吧。

2. ML-KEM 是 NSA 发明的吗?

不是。它最初由多位欧洲密码学家组成的团队定义;可以在他们的网站上查看成员名单。

3. 好吧,但那是 Kyber,不是 ML-KEM;NSA 修改了 Kyber 吗?

没有。Kyber 与 ML-KEM 之间的差异非常小,主要是 NIST 所作的编辑性修改。唯一称得上有些实质意义的变化,是对某些密钥派生机制进行了轻微调整。这项修改由 Kyber 的原作者之一 Peter Schwabe 提出,而且分析起来相当直接。修改的原因是,Kyber 最初通过加入一个 KDF 步骤,可以生成任意长度的共享秘密。然而,应用通常还需要对共享秘密应用自己的 KDF,以便将共享秘密与会话记录等信息绑定,因此最终会调用两次 KDF。由于 Kyber 使用 KDF 仅仅是为了扩展输出,移除它可以略微提升算法性能,而不会产生任何安全影响。简而言之,某项功能后来被证明在真实场景中其实算不上功能,于是 NIST 在审慎考虑、该方案作者本人明确建议这样做,并且整个密码学界都密切关注的情况下将其删除。这里没有发生任何不当行为。

补充编辑(2026-07-09):NIST 所做的一项小改动最近又被一位声名扫地的前密码学家翻了出来,也就是所谓的“耻辱哈希”(hash of shame)。在 Kyber 草案中,封装方从随机数生成器取得随机值后,会先对这个随机值进行哈希,再继续执行封装算法。应 Markku 和Sophie Schmieg 的要求,NIST 删除了这次额外哈希。最初加入它是为了防御 DUAL_EC_DRBG;要利用 DUAL_EC_DRBG 的后门,必须取得 DRBG 未经处理的输出。然而,防范这个问题简单得多的方法,就是不要使用 DUAL_EC_DRBG。随机数生成器(包括 TRNG 和 DRBG)对任何密码算法的安全运行都至关重要。TRNG 和 DRBG 都存在多种失效模式,而 DUAL_EC_DRBG 式后门只是其中之一。DUAL_EC_DRBG 从来都不是特别流行的 DRBG,因此 NIST 将其弃用并没有遇到多少阻力。在Sophie Schmieg 的职业生涯中,其从未见过它的实现,更不用说实际部署。Sophie Schmieg 倒见过很多糟糕的随机数生成器,但它们没有一个能靠不加区分地额外做一次哈希来修复。因此,这个哈希虽然可以作为抗议国家行为者蓄意削弱标准的一种姿态,却不应出现在最终标准中,因为它只会拖慢算法,得不到任何收益。弱随机数生成器当然是一个值得担忧的问题,但解决办法应当是修复随机数生成器,而不是在上一层临时发明一种新的 DRBG。

4. 好吧,但里面会不会仍然存在某种后门?

ML-KEM 中没有后门,而且Sophie Schmieg 可以证明这一点。某种机制要成为后门,特别是“只有我们能用的后门”(Nobody But Us,NOBUS),就必须确保其他人无法利用它。否则,它就不是后门,而只是一个已经被攻破的算法;你掌握的任何内部密码分析成果,最终也会被学术界追上。因此,一个有用的后门要求植入者拥有某种无法通过暴力破解获得的秘密;这个秘密相当于一把私钥,可以解开该算法产生的任何密文。这正是 DUAL_EC_DRBG 中的后门类型。考虑到美国自己也打算使用 ML-KEM——不同于当年的出口密码闹剧——这也是他们唯一有理由植入标准的后门类型。

然而,如果存在一把无法暴力破解的私钥,就还必须存在相应的公钥;这个公钥必须足够大,才能抵抗暴力破解,而且必须作为参数嵌入算法。要达到不可暴力破解的程度,该公钥至少需要具有 128 位熵。由此,得到了一种很好的测试方法,用来判断某个方案是否有能力容纳密码学意义上的 NOBUS 后门:把参数空间的熵全部加起来。如果结果明确少于 128 位,那么该方案最多只能是已被攻破,而不可能被植入这种后门。

下面就对 ML-KEM 做这个计算:

这就是它的参数集合。下面把各项熵加起来,并完全忽略这些选择实际上远比任意随机整数受到更多约束这一事实(不过在合计时仍会采用较大的数值)。

  • 数域的阶:8 位(实际上它必须是 2 的幂,所以其实只有 3 位)
  • 素数:12 位(实际上它必须是素数,所以是 10.2 位;再进一步说,它还必须是形如k ⋅ n + 1 k\cdot n+1kn+1的素数,至少要达到秩与阶乘积的两倍,而 3329 恰好就是满足这些条件的最小素数)
  • 模的秩:3 位(模的秩本身就是主要安全参数,实际只是在 2 到 4 之间计数)
  • 秘密项与误差项的界:2 + 2 位(实际上,这些值由素数大小、模的秩和数域阶共同决定)
  • 压缩强度:4 + 3 位

总计为 34 位,而且这个估算已经宽松得过分。甚至还给所有小数字额外送了一位!任何公钥只有 34 位的非对称密码系统,都能被一台笔记本电脑在几分钟内暴力破解;这样的 ML-KEM 不会是“带后门”,而会是彻底被攻破。ML-KEM 中不存在后门,因为 ML-KEM 根本没有藏下后门的空间。

为了再确认一次,如果对著名的后门算法 DUAL_EC_DRBG 应用同样的“统计参数位数”测试,就会看到标准中毫无理由地定义了多个椭圆曲线点,参数熵立即突破了 128 位预算。事实上,只要采用所谓的“袖中无物”(Nothing up my sleeves)范式,就能轻易修复 DUAL_EC_DRBG:不要让那些椭圆曲线点毫无解释地摆在那里,而应从π \piπe ee的数字,或者某个公开种子的哈希输出中派生它们。即便如此,它依然无法通过本测试;但这是因为在此故意把测试设计得过于激进。正如括号中的说明所示,这些参数其实没有多少真正的选择空间,它们只不过是能够得到安全方案的最小参数集合(增大它们只会让方案变慢和/或增加开销)。

所以,不,ML-KEM 中没有后门。

5. 但 NIST 在选择 ML-KEM 时,不是连基础数学都算错了吗?

没有。事实上,Sophie Schmieg 2023年11月专门写过一篇博客Kyber512’s security level 讨论这个话题,不过用一个“没有”概括全文也是准确的。

6. 我以为 ML-KEM 已经被攻破了,好像与故障攻击有关?

ML-KEM 的确存在故障攻击。如果你了解什么是故障攻击(也称毛刺攻击),这并不特别令人意外。进行故障攻击时,需要在算法计算过程中注入一个错误——也就是故障。可以通过干扰物理硬件来实现,如 ROWHAMMER 这类会在计算进行时直接改变内存内容的攻击。分析此类失效非常重要,但现实中存在的任何实用密码算法都会受到故障攻击的影响。

这实际上就是计算机连自己唯一的工作都没做好,没有正确计算。CPU 和内存攻击可能是人们掌握的最强大攻击类别之一,而且事实证明它们极难缓解。算法面对这种攻击时失效并不令人惊讶;毕竟,如果你能任意翻转一个比特,完全可以直接把verified_success设为true,然后收工。严格来说,这是最强形式的故障攻击,即攻击者可以选择故障发生的位置。但即使是随机故障,通常也足以摧毁几乎所有密码算法。我们知道这些攻击的存在,只能证明该算法被认为足够重要,值得人们从数学上精确研究:当你真的抽走它脚下的地板时,它究竟会怎样失效。

7. 那解密失败攻击呢?听起来很吓人!

ML-KEM 有一个奇怪的特性:从理论上说,确实有可能以完全诚实的方式生成一份密文,却被私钥持有者拒绝。如果成功做到这一点,就能获得关于私钥的信息。但关键在于:生成这种“有毒密文”的唯一方法,是诚实运行封装算法,然后期待自己走运。确实存在一种可以让密文分布略微偏斜的方法,但即便如此,仍然必须实际计算这些密文,而且得到的优势微乎其微,因为 ML-KEM 几乎替封装方决定了所有选择。利用相对直接的数学方法——柯西–施瓦茨不等式——可以计算出这种解封装失败的概率。ML-KEM 的参数经过专门选择,使实际概率小到几乎可以忽略,低于1 : 2 100 1:2^{100}1:2100。到了这个数量级,攻击者实际上已经不能假定自己观察到的是解封装失败,因为还有许多其他极不可能的事件反而更有可能发生,如宇宙射线同时造成足够多次比特翻转,并逃过错误检测。的确,观察到第一次解封装失败后,攻击者就有了更多手段让局面朝有利方向发展;但要做到这一点,首先必须让第一次失败发生,而这基本没有希望。

除此之外,一把普通的 ML-KEM 密钥通常只使用一次——这正是密钥交换所用密钥的命运——进一步使此类自适应攻击失去意义。不过,即使对同一把密钥执行多次解封装,ML-KEM 密钥依然安全。

8. 但不是还有一个叫 KyberSlash 的问题吗?

是的。事实证明,实现密码代码仍然很难。可以稍微自夸一下:Sophie Schmieg的实现后来逐渐演变为 BoringSSL 的 ML-KEM 实现,而它从未出现过这个问题。所以这里的答案大概是“变强一点”(git gud)之类的吧。不过说正经的,特别是在早期阶段,新实现总会有一些毛刺;随着人们逐渐掌握避免这些问题的正确技术,情况才会改善。重要的是,这是实现中的缺陷,而不是算法数学结构中的缺陷。事实上,好消息是,从实现角度看,ML-KEM 其实比椭圆曲线简单得多,所以这种小型侧信道问题在这里可能会更少;只是人们实现 ML-KEM 的次数还不像实现椭圆曲线那么多。

9. 好吧,ML-KEM 先说到这里;混合方案和 IETF 又是怎么回事?

好吧,这件事确实挺有趣——前提是你喜欢严重失灵的细枝末节争论、故意曲解和各种戏剧性冲突。首先,什么是混合方案?假设你有两个功能相同的密码方案,而且两个都不信任,但你信任二者的组合。混合方案本质上正是为了实现这一点:把两个相同类型的方案组合成一个,使组合方案至少与其中任意一个同样安全。通常的说法是,这非常适合 PQC,因为它能把经过充分研究的经典方案安全性与 PQC 方案的抗量子能力结合起来。此外,与格密码相比,椭圆曲线密码的额外开销微乎其微,那为什么不顺手加上呢?总体上Sophie Schmieg赞同这种立场。不过,Sophie Schmieg对格密码的信任程度与对椭圆曲线的信任程度基本相同,而且远高于对 RSA 的信任程度,因此Sophie Schmieg并不认为混合方案在任何时候、任何地方都绝对、永远、超级无敌地不可或缺。但它们基本不增加成本,所以为什么不用?最终结论是:没错,混合方案是最佳选择,而 IETF 的确也让人们能够这样做。已经有多份相关 RFC。要理解当前争议,需要聚焦于两个与 TLS 有关的方案:X25519MLKEM768(又称 0x11EC)和 MLKEM1024。前者是混合方案,后者不是。与上述推理完全一致,0x11EC 是 Chrome、Firefox 以及几乎所有当前支持 PQC 的 TLS 客户端所采用的默认密钥交换算法。那么 MLKEM1024 有什么意义?事实证明,有一个客户真的、真的非常讨厌混合方案,只想在自己的所有系统中使用 ML-KEM1024,而这个客户恰好就是 NSA。说实话,这看不出这有什么问题。如果 NSA 想让自己的系统效率更低,那是他们的选择。为什么会更低效?由于 TLS 的工作方式存在一些特性,客户端需要预测服务器可能接受什么。客户端可以多预测几种,但 PQC 密钥相当壮硕,同时发送多把 PQC 密钥会让握手变慢。预测错误同样会拖慢握手,因为服务器会回应:“再试一次,这回请使用正确的公钥。”因此,如果除了 NSA 以外的所有人都使用 X25519MLKEM768,主要结果只是 NSA 的握手速度更慢。如前所述,Sophie Schmieg不认为可以合理地说他们的握手安全性明显更低;不过,如果你真的认为 ML-KEM 已被攻破,那么没错,NSA 成功破坏了 IETF,好让自己的系统变得更不安全,同时不影响任何其他人。那就恭喜他们吧,大概。

10. 但 IETF 不是在积极劝阻人们使用混合方案吗?

没有。要理解这一点,需要看看 TLS 密钥交换算法附带的两个标志:Recommended(推荐)和 Mandatory To Implement(强制实现,MTI)。Recommended 标志有三个取值:Yes、No 和 Discouraged。Discouraged 用于已知被攻破的算法,如 RC4。显然,无论是否采用混合形式,ML-KEM 都没有被确认攻破,因此 Discouraged 并不适用。0x11EC 确实没有被标记为 Recommended,主要是因为它最初只是一个实验性组合,后来不知怎么就变成了所有人都在用的东西。尽管人们为了争论是否应该推荐它耗费了大量“数字墨水”,但在 RFC 发布之前,没有人更新这个标志。(严格来说,该 RFC 尚未发布,不过其余流程基本只是手续,而且这个标志不太可能改变。)所以,是的,从技术上讲,IETF 并未推荐一种混合算法。但你的浏览器和其他所有人都在使用它,这一点也摆在那里。另外,如果你担心的话,NSA 选用的 MLKEM1024 同样没有被标记为推荐。

补充编辑(2026-06-30):此后,IETF 最终更新了 IANA 注册表,将 0x11EC 的标志改为推荐。纯 MLKEM1024 仍然未被推荐。

最后,Mandatory To Implement 是 TLS 发明者精心设计的一个恶作剧,目的是让邮件列表里出现更多争论。正如 David Benjamin 曾经说过的,真正强制实现的唯一算法是“空算法”(null algorithm),因为 TLS 连接在协商出算法之前,其初始状态就叫这个名字。除此之外,至少Sophie Schmieg的建议是:每当有人要求你支持一个你不想支持的 MTI 算法时,就回复下面这张动图:

这个标志实际上毫无意义。哦,对了,上述两个算法都不是 MTI。

11. 补充编辑:加赛环节

这篇博客发布后,又收到了一些问题,因此把它们补充在这里。

11.1 IETF/浏览器/服务器的支持不会让我们遭受降级攻击吗?

不会。TLS 密钥协商可以抵御降级攻击。如果你的浏览器已经大约十年没有更新,它或许容易受到降级至 SSL3 的攻击;不过在这种情况下,也不会再担心 PQC 了。

更具体地说,客户端支持的密码套件列表和服务器选择的密码套件都会加入密钥派生过程,因此任何对这些选项的篡改都无法成功协商出 TLS 1.3 密钥。TLS 1.3 的降级保护甚至更有意思:一台本可支持 TLS 1.3、却正在协商 TLS 1.2 的服务器,需要设置一个特定的服务器随机值,以向客户端表明它其实更希望使用 TLS 1.3。这些机制共同保护 TLS 1.3 的密钥协商,因此,额外加入客户端和服务器都不优先选择的密钥协商方案,并不会导致它们最终被选中。

11.2 但 NSA 为什么不喜欢混合方案?

最初没有写这一点,因为只能告诉你 NSA 声称自己为何不喜欢混合方案,并评估这些理由是否合理;但无法告诉你这些是否是其真实原因。

就其公开理由而言,基本有三点反复出现:

  • 担心组合爆炸导致互操作性问题。
  • 由于已经使用双重加密,因此没有采用混合方案的必要。
  • 希望向世界其他地方——显然也包括美国政府内部的某些部门——表明 NSA 信任格密码。

对于第一点,他们的判断算是对了一半:确实见到了巨大的组合爆炸,因为人们拼命要求支持自己最喜欢的经典方案和最喜欢的 PQC 方案,导致 LAMPS、CFRG 和 PGP 工作组定义了数量多到有些荒谬的混合方案。然而,TLS 密钥协商并没有掉进这个陷阱。那里只有一种混合算法,而且所有人似乎都喜欢并在使用它。需要注意的是,NSA 主张不使用混合方案的 CNSA 2.0 指南,早在 Kyber 最初的实验——后来逐渐演变成 0x11EC——之前就已经出现。

对于第二点,需要知道的是:显然在处理高度敏感的信息时,情报活动中已经普遍采用两次加密,而且两层技术栈由完全不同的供应商实现。这很合理,因为它既能防御内部威胁,也能防范实现错误,尽管代价是显著的性能损失(不知道他们是不是根本没有对性能敏感的绝密任务)。既然已经具备这种能力,就可以让其中一层使用经典密码,另一层使用 PQC,从而构造混合密码,而无须使用混合密钥交换。

最后一点更多存在于字里行间,也曾在一些较为非正式的对话中出现:NSA 必须表明,他们以及为其工作的那一大群数学家确实信任 PQC 算法。对其他任何组织来说,采用混合方案可能只是看起来谨慎;但如果 NSA 也这样做,完全有理由怀疑,他们是否真的足够信任 PQC,认为它可以投入部署。通过强制使用纯格密码——但只用于自己的系统——他们用行动证明了自己的立场。最终,这意味着如果格密码或 ML-KEM 真的被攻破,面临风险的只会是他们自己的系统。

初步看来这些都是合理的论据,但它们当然不代表这一定就是该组织的真实动机。还要记住,和任何大型组织一样,NSA 内部未必存在一种统一意见,可能只是不同个体各有不同动机。

11.3 如果真的想给 MLWE 植入后门,可以做到吗?它会是什么样子?

MLWE 是 ML-KEM 背后的基础机制,是对问题更一般化的数学描述,而不是具体规定哪些字节放在哪里。如果想给它植入后门,实际上确实可以。将以 RLWE——MLWE 的环版本——来说明;二者原理相同,但环的形式更容易写清楚。RLWE 的公钥a , t a,ta,tt = a s + e t=as+et=as+e计算,其中a aa是任意数域整数,而s , e s,es,e是短数域整数。要攻击它,首先构造一个格,其中包含所有满足0 = a p + q 0=ap+q0=ap+q的数域整数对( p , q ) (p,q)(p,q);然后在这个格中,寻找最接近某个特解t = a s ′ + e ′ t=as'+e't=as+e的格向量。按照最近格点的定义,这个最近格向量与特解( s ′ , e ′ ) (s',e')(s,e)之间的差很短,而且它等于原始秘密(或至少具有与原始秘密等价的能力)。RLWE 的安全性来自这样一个事实:当a aa随机选取时,计算这个最近向量非常困难。因此,如果想给 RLWE 植入后门,只需不随机选择a aa,而是先选择短的p , q p,qp,q,使得在模该素数的意义下a = − q / p a=-q/pa=q/p。对任何外部观察者来说,这类a aa与真正随机生成的a aa无法区分,而攻击者却能攻破由它生成的任何公钥(事实上,另一种稍有不同的格密码方案 NTRU 正是以这种方式工作的)。

因此,如果想给 MLWE 类算法植入后门,只需要规定一个固定矩阵A AA(它是 RLWE 中整数a aa的高维对应物),并要求所有密钥生成都使用它。如果这个矩阵随机生成,那么方案是安全的;如果它包含后门,那么除非整个格密码都已被攻破,否则人们无法区分随机矩阵与带后门的矩阵——除非使用“袖中无物”变换,如通过对公开种子做哈希来生成矩阵。

但是,这种做法无法通过前面提出的测试。矩阵A AA包含 4 到 16 个模 3329(ML-KEM 所用素数)的数域整数元素,每个数域整数又包含 256 个元素(数域阶),因此这样的参数会给总数增加惊人的 12288 到 49152 位。这说明该测试能够成功发现此类问题。

如果好奇,ML-KEM 选择矩阵的方法非常简单:每个公钥都有自己独立的随机矩阵。只有执行密钥生成的人可能给该矩阵植入后门,但无论如何,他们本来就拥有私钥。事实上,他们甚至连这样做都不行,因为 ML-KEM 通过只把一个派生种子放入公钥来压缩矩阵。

11.4 密码学意义上的 NOBUS 后门真的是唯一选择吗?

已经证明这里不可能存在密码学意义上的 NOBUS 后门,但它真的是唯一选择吗?简而言之,是的。

让人困惑的是,实现中可以存在复杂得多的后门,因为任何测试都无法保证程序对所有查询都作出正确响应,只能保证它对测试过的查询作出正确响应。然而,算法并非如此。

任何想植入算法的后门,都必须写进算法本身的数学描述,因为任何人都可以选择从零开始实现给定算法,并期待它能够与其他实现互操作。这样一来只剩两种选择:一种后门理论上任何人都能发现和利用,也就是算法本身已被攻破;另一种后门即使被发现,也只有植入者可以利用,也就是 NOBUS 后门。前一种会让算法同样不适合植入者自己使用,因为这些算法会受到严格审查,任何有兴趣的参与者都很可能迟早发现这种后门。第二种则必须包含某种具有足够熵的秘密,否则攻击者只需遍历植入者可能掌握的所有值,就能找出正确值;换句话说,这个后门会再次沦为第一种。

补充编辑(2026-07-01):Sophie Schmieg 见过这种论证的一个变体:会不会存在一种只影响一定比例密钥的破解方法,也就是所谓的弱密钥问题?掌握这种破解方法的国家行为者,可以在密钥生成算法中添加额外代码,使自己的实现避开该问题,同时仍然能够破解数量不可忽略的通信流量。然而,这同样不是 NOBUS 后门:任何人只要阅读规范,就有可能发现这个问题。这意味着它迟早会被其他对手或公众发现。一个只关心自身通信、并能高度控制所有生成和接收这些通信的端点的对手,或许确实没有太强的动机公开这种弱点。然而,由于安全算法此时已经不再遵循规范——即使外部看不出这种偏离——这个对手也无法再把实现外包给第三方,因为第三方会按照原始且有缺陷的规范来实现。事实上,由于密码结果通常与随机值不可区分(不过对 ML-KEM 而言,不是与均匀随机值不可区分),他们完全可以在内部运行另一套不同的算法,根本无须考虑该标准的防御性用途。更糟的是,如果这个对手不能控制所有端点,或者关心自身通信之外的流量,也就是说,对该标准存在任何防御利益,那么它又会让其他人能够攻破这种加密。在除该对手之外的所有人都使用混合方案的情况下,只要经典密码仍然安全,基本不会发生什么。总体而言,“如果存在一些只有 NSA 知道的弱密钥怎么办”这个问题,与“如果 NSA 在精心上演一出偷梁换柱的戏码,表面上宣传并外包大量 ML-KEM 工作,实际上却秘密使用完全不同的东西怎么办”基本等价。

参考资料

[1] Sophie Schmieg 2025年11月27日博客 ML-KEM Mythbusting

http://www.cnnetsun.cn/news/4242296.html

相关文章:

  • 蓝牙传感器开发新范式:Lynx库如何统一固件与App数据链路
  • 生物医学信号处理(北京工业大学)第二章
  • SPADE框架:可执行环境+自对弈+共进化,让AI自己生成训练环境
  • 用 Python 驱动 COMSOL 自动化仿真:6 行代码跑通
  • 刚刚,ChatGPT 开始卖广告了!
  • 什么是 SAP HANA Cloud 内置的 Property Graph Engine(属性图引擎)
  • BiliTools 开源 B站下载工具:把番剧、音乐、弹幕存到本地
  • 多模态图Transformer预训练:构建下一代推荐系统基础架构
  • E27灯座电流钳测试实战:从原理到精准测量的完整指南
  • AI服务器涨价超15%:内存成本飙升背后的工程应对之道
  • AI问答努力程度选择器实现指南:从粒度设计到前后端参数映射
  • Lodash.js核心函数实战指南:提升JavaScript工程效率
  • 医疗AI Agent执行层为何绕不开X12标准?工程实践指南
  • 零基础入门具身智能:从运动控制到ROS2工程实践
  • Win10专业版卡顿重装系统全指南:判断、备份、安装与优化
  • 临床数据建模实战:时间对齐、语义校验与诊疗逻辑嵌入
  • 用LangChain只会调包?3处源码让你从调包到掌控,效率翻倍
  • MATLAB工程师实战指南:从矩阵哲学到工业级避坑
  • 数学建模竞赛中聚类算法实战:从DBSCAN到K-Means的选型与应用
  • Matlab实战社交推荐:从协同过滤到矩阵分解的数学建模
  • 数学建模竞赛中黄河水沙数据的时空特征分析与Python实现
  • 01-python自动化测试学习路线
  • 京东商品库存监控自动下单:10分钟跑通 jd-happy 全流程?
  • DBX--开源、轻量的数据库与数据基础设施工作台
  • 华为MetaERP # Oracle EBS FA 资产业务层 —— 资产主数据完整深度解析## 前置架构边界EBS FA 分层回顾:1. **资产业务层**:资产主数据、资产事务引擎、分
  • CSP-J 初赛(以满分为目标):第十课《排序算法基础——让一群“乱站的同学”排好队》
  • 车载 ECU 信息安全入门:一文看懂安全启动(Secure Boot)原理
  • 降低aigc免费网站怎么选?知网维普万方AI降重和查重适配实测
  • jsoncpp的编译和使用
  • OPC 本质探索:OPC 真的是赚快钱的好工具吗?——一人公司创业的本质、风险与合规