<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Side-Channel on As it was</title>
    <link>https://galoishlee.github.io/tags/side-channel/</link>
    <description>Recent content in Side-Channel on As it was</description>
    <generator>Hugo</generator>
    <language>zh-CN</language>
    <managingEditor>maocred@gmail.com (Halois)</managingEditor>
    <webMaster>maocred@gmail.com (Halois)</webMaster>
    <copyright>This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.</copyright>
    <lastBuildDate>Sat, 30 May 2026 20:37:52 +0800</lastBuildDate>
    <atom:link href="https://galoishlee.github.io/tags/side-channel/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Solving LWE with Independent Hints about Secret and Errors — Lu, Feng, Pan (2025)</title>
      <link>https://galoishlee.github.io/lattice-hints-lu2025/</link>
      <pubDate>Wed, 27 May 2026 12:00:00 +0800</pubDate><author>maocred@gmail.com (Halois)</author>
      <guid>https://galoishlee.github.io/lattice-hints-lu2025/</guid>
      <description>&lt;p&gt;Reading: Lu, Feng, Pan (2025). &lt;em&gt;Solving LWE with Independent Hints about Secret and Errors.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;问题设定：&lt;/strong&gt; 给定 LWE 实例 \((A, \mathbf{b} = \mathbf{s}A + \mathbf{e} \bmod q)\) 和一组精确的侧信道 hint（关于 \(\mathbf{s}\) 或 \(\mathbf{e}\) 的内积值），构造 primal attack 格基进行密钥恢复。&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;本文的改进：&lt;/strong&gt; 将 Nowakowski-May (ASIACRYPT 2023) 嵌入 hint 时使用的 LLL 约简替换为 Hermite 标准型（HNF）——一个多项式次数更低的整数线性代数操作。Kyber512 上 234 个完美 hint 的基构造从 2.16 小时降至 0.35 小时。格基维度与行列式与 MN23 等价，对完美 hint 行列式略有增大。&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;本笔记关注：&lt;/strong&gt; (1) 构造链——hint 转为 lattice hint 后如何通过矩阵乘法嵌入 primal attack 格基；(2) HNF 比 LLL 快在哪——多项式次数的差距及其工程含义；(3) 论文未说但值得追问的部分——带噪 hint、联合 hint、attack pipeline 完整评测的缺失。&lt;/p&gt;</description>
    </item>
    <item>
      <title>椭圆曲线签名的安全性分析：从 ECDLP 到 HNP、EC-HNP 与 EHNP</title>
      <link>https://galoishlee.github.io/ecc-security-hnp-ehnp/</link>
      <pubDate>Sat, 13 Dec 2025 08:00:00 +0800</pubDate><author>maocred@gmail.com (Halois)</author>
      <guid>https://galoishlee.github.io/ecc-security-hnp-ehnp/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;Reading: ECDLP is the baseline, not the whole risk surface.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;前两篇已经把 ECC 子系列里最容易混淆的两件事拆开了: 哪些协议只消费普通离散对数群，哪些协议需要 pairing；以及为什么账户层长期绑定 secp256k1。这一篇继续沿着账户层往下走，但焦点不再是“签名接口长什么样”，而是“签名接口在哪里失守”。&lt;/p&gt;&#xA;&lt;p&gt;对椭圆曲线签名来说，曲线层首先给出的安全基线是 &lt;code&gt;ECDLP security assumption&lt;/code&gt;。如果敌手只能看到公钥 $P=dG$，却拿不到关于私钥 $d$ 和临时标量 $k$ 的额外泄漏，那么攻击目标仍然是离散对数问题本身。但真实系统并不总是在这个理想模型里运行。wallet and signing implementations 会暴露 nonce 生成、缓存访问、功耗、分支、fault handling 和接口复用等边界，而这些边界往往把问题从“解曲线上的离散对数”改写成“恢复带泄漏的 secret scalar”。&lt;sup id=&#34;fnref:1&#34;&gt;&lt;a href=&#34;#fn:1&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;1&lt;/a&gt;&lt;/sup&gt; &lt;sup id=&#34;fnref:2&#34;&gt;&lt;a href=&#34;#fn:2&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;2&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;&#xA;&lt;p&gt;ECDSA 的危险点尤其集中在 nonce。只要签名方程里的 nonce 有重复、偏置、部分泄漏，或者可由 side-channel trace 提供不完整信息，攻击者面对的就不再是 black-box ECDLP，而是某种 hidden-number style relation。也正是因此，HNP / EC-HNP / EHNP 不是只存在于格论教科书里的标签，而是现实账户系统在弱随机数、硬件钱包、远程 signer 和实现缺陷下会真正碰到的攻击视角。&lt;sup id=&#34;fnref:3&#34;&gt;&lt;a href=&#34;#fn:3&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;3&lt;/a&gt;&lt;/sup&gt; &lt;sup id=&#34;fnref:4&#34;&gt;&lt;a href=&#34;#fn:4&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;4&lt;/a&gt;&lt;/sup&gt;&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;Quick Note.&#xA;This article connects ECDSA nonce leakage to hidden-number style linear constraints. It also distinguishes HNP, EC-HNP, and EHNP rather than flattening them into a generic lattice-attack label, covers nonce bias, partial leakage, and side-channel trace models relevant to wallet and signing implementations, and separates curve-level security from implementation leakage and protocol misuse.&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>Lattice Part 10: Implementation Fault Lines in Lattice Cryptography</title>
      <link>https://galoishlee.github.io/lattice-part-10/</link>
      <pubDate>Fri, 25 Oct 2024 12:00:00 +0800</pubDate><author>maocred@gmail.com (Halois)</author>
      <guid>https://galoishlee.github.io/lattice-part-10/</guid>
      <description>&lt;p&gt;Reading: Peikert&amp;rsquo;s survey as the wide-angle frame&lt;sup id=&#34;fnref:1&#34;&gt;&lt;a href=&#34;#fn:1&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;1&lt;/a&gt;&lt;/sup&gt;, NTRU Prime&amp;rsquo;s attack-surface language&lt;sup id=&#34;fnref:2&#34;&gt;&lt;a href=&#34;#fn:2&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;2&lt;/a&gt;&lt;/sup&gt;, NIST&amp;rsquo;s standardized ML-KEM / ML-DSA interfaces&lt;sup id=&#34;fnref:3&#34;&gt;&lt;a href=&#34;#fn:3&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;3&lt;/a&gt;&lt;/sup&gt;&lt;sup id=&#34;fnref:4&#34;&gt;&lt;a href=&#34;#fn:4&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;4&lt;/a&gt;&lt;/sup&gt;, and the implementation-attack papers that target Kyber, BLISS, Falcon, and lattice decapsulation itself&lt;sup id=&#34;fnref:5&#34;&gt;&lt;a href=&#34;#fn:5&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;5&lt;/a&gt;&lt;/sup&gt;&lt;sup id=&#34;fnref:6&#34;&gt;&lt;a href=&#34;#fn:6&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;6&lt;/a&gt;&lt;/sup&gt;&lt;sup id=&#34;fnref:7&#34;&gt;&lt;a href=&#34;#fn:7&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;7&lt;/a&gt;&lt;/sup&gt;&lt;sup id=&#34;fnref:8&#34;&gt;&lt;a href=&#34;#fn:8&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;8&lt;/a&gt;&lt;/sup&gt;&lt;sup id=&#34;fnref:9&#34;&gt;&lt;a href=&#34;#fn:9&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;9&lt;/a&gt;&lt;/sup&gt;&lt;sup id=&#34;fnref:10&#34;&gt;&lt;a href=&#34;#fn:10&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;10&lt;/a&gt;&lt;/sup&gt;&lt;sup id=&#34;fnref:11&#34;&gt;&lt;a href=&#34;#fn:11&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;11&lt;/a&gt;&lt;/sup&gt;. Part 10 closes the lattice subseries at the only boundary that really matters in deployment: proof-level security is about an abstract construction, while deployed security is about the arithmetic, randomness, control flow, and fault behavior that actually reach silicon.&lt;/p&gt;&#xA;&lt;p&gt;From Parts 0-3, read every deployed scheme as a concrete implementation of modular lattice relations over short coefficient vectors. Structured rings and modules buy compactness because multiplication becomes regular and sampling stays cheap enough to ship. The same structure also narrows the implementation surface into a few hot loops: NTT butterflies, modular reductions, coefficient compression, rejection tests, hint generation, and decapsulation compares. Those loops are exactly where timing, power, cache behavior, and induced faults start to expose data that the proof never modeled.&lt;/p&gt;&#xA;&lt;p&gt;The useful split is therefore not &amp;ldquo;lattices have side channels too.&amp;rdquo; That is too generic to help. The useful split is KEM versus signature. A KEM exposes a decapsulation oracle whose correctness margins and implicit rejection logic can be probed adaptively. A signature scheme exposes a signing loop whose sampler and abort logic must maintain the right distribution across many signatures under one long-term key. Same hardness family, different failure physics.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
