密码学 39：结课二——经 HTTPS 提交交易，分别验证通信与账本
钱包用 HTTPS RPC 提交了一笔“支付测试订单”的 Ethereum 交易，RPC 返回哈希，收据显示 status=1。这意味着什么？它不意味着现实商家已经履约；更不意味着仅凭一个 HTTPS 连接，就能信任 RPC 提供的区块头在预期链的共同历史中。本结课真正需要的，是在同一条实际传输路径上把通道身份、签名授权、规则/状态、交易包含、最终性与现实结果逐个分开，并对错身份、重放和错链给出独立失败证据。 一张贯通图：五问各向谁要答案 1234567891011钱包：临时私钥 ──► type-2 签名交易原始字节 │ └─► 签名：授权指定链 ID、nonce、收款账户、金额、费用 └── TLS 1.3 + 临时 CA 验服务名 orders.test ──► 本地 HTTPS /rpc │ ▼ ...
密码学 E01：TLS 1.2 的 RSA 密钥传输与 ECDHE——历史资料为什么容易混淆
读到一篇旧文章：“服务器用 RSA 证书，所以 HTTPS 把会话密钥用服务器 RSA 公钥加密发送。”另一篇说：“服务器仍是 RSA 证书，却使用了 ECDHE。”两者不必矛盾：证书公钥的算法、服务器握手认证用的签名算法、双方建立共同秘密用的密钥交换算法，是三个问题。尤其不能把 TLS 1.2 的两种方案不加区分地复述成 TLS 1.3 的流程。 谁算秘密，谁验身份 历史 TLS 1.2 RSA key transport 中，客户端生成 pre-master secret，用服务器叶证书中的 RSA 公钥按相应握手规则加密发送；拥有 RSA 私钥的服务器解开。证书和主机名检查必须先说明客户端为什么接受这把公钥，否则攻击者换自己的公钥就能解出秘密。若当时的加密流量被记录，且后来服务器证书 RSA 私钥泄漏，历史握手所依赖的这份私钥可能使旧连接被解开；这个方案缺乏由独立临时 DH 秘密带来的前向保密边界。 TLS 1.2 的 ECDHE_RSA 则使用双方的临时椭圆曲线 DH 点计算共同秘密，用服务器 RSA 密钥对关键握手参数做身份认证；不能说“RSA 公钥加密了共同秘密”。如...
密码学 35：有效性证明为什么不自动给出隐私、可用性与最终结果
假设一个系统展示了“新状态根有有效证明”，但就是不公布用户这批交易的数据。用户能仅凭一个证明恢复自己账户的状态、重新计算余额，或者安全退出吗？不能直接推出。反过来，把交易数据都发出来，也不等于状态转移经过证明，更不等于实际链已经结算、具有要求的最终性。一个有效性证明只证明它明确编码的关系，不会越过规范的边界替运行者承担数据服务、社会共识或现实交付责任。 把批次拆成五个问题 给定旧状态根 S、新状态根 S′ 和必要的批次公开输入，一份有效性证明可以约束“存在满足给定转移规则的见证，使旧状态按该关系得到 S′”。要达到可用状态还须检查具体证明系统/电路究竟约束了什么：若没有约束签名、交易顺序、余额或者提现条件，验证者不会凭想象补上。再检查证明是否已由期望的结算层或合约接受；“有人本地验真一份 proof”和“相关状态已在期望链上确认”是两种证据。 数据可用性问第三方是否能拿到重建状态、观察账户或退出所需的数据，约束证明真假不能让被扣留的原始字节自动出现。链上发布、外部数据层和有效性证明各有验证和信任假设；即使某阶段可下载，也不表示有永久存储保证。隐私问公开了什么：包含证明和合法性证明...
密码学 E02：后量子 KEM、ML-KEM、ML-DSA 与混合握手
有人说：“换成后量子算法以后，把 ML-DSA 签名加进握手，就能替代密钥交换。”这是把两件不同操作放在一个盒子里：ML-KEM 用于建立双方一致的秘密，ML-DSA 用于证明特定消息由签名密钥持有者授权。KEM 共享秘密匹配也不会自动认证发送密文的一端；签名验真也不会自动证明自己与另一端共享了对称记录密钥。旧的量子风险解释应具体指出 RSA/ECDH 的困难假设面临哪类威胁，不能因为“后量子”三个字就宣称工程已经抵抗了未来所有攻击。 KEM 的四个输入输出 受信任的接收方发布 ML-KEM 公钥，保留私钥。发送方拿到已正确绑定身份的公钥后执行封装：输入公钥与随机源，输出可发送的密文 cipherText 以及自己的共享秘密 sharedSecret；接收方对同一密文用私钥解封装，得到相同共享秘密。发错私钥或改封装密文时，许多 KEM 采用隐式拒绝：返回不同的秘密而非清晰抛出“认证失败”。随后必须在有身份约束的协议里通过 transcript/Finished 或应用认证发现双方秘密不一致，不能把“函数没有报错”写成“双方已认证”。 ML-DSA 则取私钥与指定消息字节生成签名，...
密码学 E03：Noise 与 WireGuard——握手模式、身份与密钥更新
有人抓到两个使用 Noise Framework 的系统，宣称“它们都是 Noise，握手双方必然相互认证、能抵抗同样的重放和身份泄露”。不一定。Noise 描述多种不同握手模式；什么静态公钥事先已知，什么身份在握手中发送，谁先能确认谁，以及之后的数据包格式，必须按具体模式和应用实现核对。WireGuard 使用相关的密码学构件和 Noise 体系的握手思路，并不是“任何 Noise 模式加一个 UDP socket”就成了 WireGuard。 从 KK 这一种模式推导身份 本章只选 Noise_KK_25519_ChaChaPoly_BLAKE2b：K 表示两端都在握手开始前已获得并信任对方静态公钥；25519 表示临时和静态密钥交换使用的曲线，ChaChaPoly 对规定的握手 payload 做认证加密，BLAKE2b 参与哈希和派生。双方交换临时公钥，混入静态/临时 DH 得出的秘密，随握手消息处理不断更新握手 hash/密钥状态。两条消息之后 split 得到两方向不同的传输 cipher state；客户端的发送状态与服务端的接收状态对应，反向同理。 1234567...
密码学 E04：多签、阈值签名与 MPC——共同控制怎样表达
三个人管理一个测试钱包，约定“任意两人同意才可转账”。业务工程师在 API 上要求两份独立签名；密码学工程师说可以做阈值签名；产品把它写成“使用 MPC”。他们可能分别描述不同层的东西：谁制定参与规则、谁看到多少份链上签名、私钥是否由一个人完整持有、多个参与者如何共同生成一份签名，不能靠一个“2/3”标签替代。多签、门限签名及安全多方计算可组合，彼此不互为定义。 先把 2/3 写成可验证操作 最直观的链上多签或应用策略是三把各自独立私钥对同一份具有域的字节签名；验证端持有三把事先被授权的公钥清单，核对至少两把不同公钥的有效签名，并检查该账户或应用的业务 nonce 已消费。若收到同一把公钥的两份相同签名，仍只有一名授权人。若改收款人或金额却复用旧签名，不能称两人同意了新交易。链上具体验收要遵循锁定脚本或合约规则；Bitcoin 和 Ethereum 的手续费、发布内容与脚本表现会不同。 阈值签名想得到另一种外观：多个持有私钥份额的参与者交互，按完整协议生成一份可由特定公钥核对的签名。数学上公钥聚合、随机数承诺、会话身份、恶意参与者/rogue-key 检查、掉线恢复等都是协议的一...
密码学 E05：SNARK/STARK 与多项式承诺——证明成本和假设从哪里来
技术选型表经常写：“SNARK 证明短、STARK 透明；换成后者就自动有零知识与永久可用数据。”这句话混淆了五个不同问题：约束什么计算、采用什么承诺及安全假设、证明/验证开销、哪些值公开、能否拿到被证明计算所需数据。如果连两边要证明的关系都不一样，比较一个 proof 的字节数没有意义；如果只用论文的性能数字比较自己没有安装过的 STARK 工具，读者就无法复核。 先固定同一关系和成本单位 34 已实际执行的一条受限关系是：私有 secret 的 Poseidon 承诺等于公开 commitment，公开 amount <= limit。这不是完整订单转账电路；在现实系统里还要约束哪些状态变化、签名授权与费用必须单独设计。Groth16 把这条关系编译为约束，随后需要与电路相关的 proving key / verification key，并依赖设置材料；本地实验只有单人临时设置。证明者提供见证，验证者持有正确的验证密钥、公开输入和 proof。验证成功仅在相应设置及电路关系正确的假设下说明这些值匹配；业务关系漏了条件时，密码学证明仍可真实有效。 多项式承诺给证明系统提...
密码学 E06：证书透明度与可验证日志——包含、追加一致性与监视
客户端信任的 CA 错给 orders.test 签了另一张证书；网站自己的 TLS 私钥并没有泄露，但攻击者若能使用那张错签证书，访问者就可能连接到错误服务。有人说：“把证书记入透明日志，错误证书就不能用了。”日志通常不能强制 CA 不签错证；它要做的是让发行行为可见、可追踪、可由监视者发现并纠正。包含证据、承诺不删改旧条目的追加一致性和有人真正检查日志，是三项不同工作。 三个验证对象 透明日志对证书或预证书做规范的叶编码，把有序叶集合构成带根哈希的 Merkle 树。包含证明用叶与路径重算到给定根；仅当客户端拿到正确、可信/可核验的树头和日志身份时，才有“这条内容属于这次树承诺”的意义。若日志给出 SCT（签名证书时间戳），那是关于未来按规则纳入日志的一项承诺，不是纳入证明，也不是该证书绝无错签的审计结论。 追加一致性回答另一个问题：先前规模为 m 的树，与后来规模为 n 的树，新的历史是否保留了老树全部条目并只在后面追加？客户端若只验某张证书在新根之下出现，不会发现旧条目被替换/删除；如果攻击者让两个客户端看到两套互相矛盾的树头，仅在同一条恶意视图内部检验还不能发现分裂视图...
密码学 E07：端到端加密与 Double Ratchet——服务器还能看见什么
消息应用说“使用 TLS 与端到端加密”，使用者就以为服务器看不到任何东西、几天前泄漏的一把密钥也永远不影响新消息。两种推论都不可靠。TLS 保护的是应用到 TLS 终止端点的传输；如果服务端要转发两人的端到端密文，它仍然通常知道账号、设备、接收方、消息时间和大小等路由元数据。端到端密钥若没有经过验证的身份绑定，服务器还可能提供错误的对端公钥。Double Ratchet 试图在会话中推进消息密钥、引入新的 DH 秘密改善泄漏后的边界；它不是“每次哈希一次同一密码”这么简单。 先画出哪把密钥在哪一端 初始密钥建立和身份认证把 A 的设备与 B 的设备绑定到某组共同材料；之后各端维持发送链与接收链等状态。从当前链密钥派生一份仅用于本条消息的 AEAD 密钥，同时派生下一条链密钥；使用后安全删除不再需要的旧材料，可在一定威胁模型下限制后来状态泄漏对早前消息的影响。接收到新的 DH 公钥后，协议按正确序列用本地私钥交换，更新根链、发送或接收链；这种新秘密的注入及正确删除旧状态，才是泄漏后恢复的一部分条件。如果攻击者持续控制端点，任何协议都不会在该端点上自动保密。 1234567A 设备...
密码学 E08：安全定义与协议审查——IND-CPA、IND-CCA、EUF-CMA
一次“改密文被拒绝”的测试能证明加密方案满足 IND-CCA 吗？不能。你观察的是某个密钥、某条消息、某次篡改；安全定义讲的是指定攻击者可以查询什么、在什么假设下对所有足够大的安全参数成功概率受到何种限制。把“有限测试通过”写成“一般证明”会让协议审查虚假完结。但安全游戏并非只给数学家看的缩写：工程师可以用它们倒推自己是否给攻击者开放了过强的接口。 三种攻击接口是三种问题 在 IND-CPA 游戏里，攻击者可查询加密 oracle，自选两个等长消息 m0,m1，得到其中一个的挑战密文，目标是猜被加密的是哪条。若同一密钥下加密确定性，攻击者提前问 oracle 加密 m0，再比较挑战密文是否相同，往往立刻赢。相反，随机化或 nonce 管理正确的加密还须具体证明安全假设，不能只因两次密文不同就断言 IND-CPA。 IND-CCA 比上述更强，允许攻击者再做受限制的解密查询（不能直接要求解挑战密文本身），让它探查畸形密文和错误处理；认证加密的必要性及错误消息边界在此更清楚。EUF-CMA 是签名的伪造游戏：攻击者可选择消息请求合法签名，之后却要给出一条未曾被授权的新消息及其可验签名...