<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Timing Attacks on Nalar</title>
    <link>https://nalar.dev/tags/timing-attacks/</link>
    <description>Recent content in Timing Attacks on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 08 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/timing-attacks/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Compare Secret Values Without Data-Dependent Early Exit</title>
      <link>https://nalar.dev/compare-secret-values-without-data-dependent-early-exit/</link>
      <pubDate>Tue, 08 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/compare-secret-values-without-data-dependent-early-exit/</guid>
      <description>&lt;p&gt;Applications compare secret-derived values in many places: webhook message authentication codes, API tokens, password-reset tokens, signed request authenticators, and other proofs that a caller knows a secret. A normal string or byte comparison may stop as soon as it finds a difference. That is efficient for ordinary data, but it can be the wrong behavior at a security boundary.&lt;/p&gt;&#xA;&lt;p&gt;If the amount of comparison work depends on where two secret values first differ, an observer may be able to learn something from repeated timing measurements. Whether that signal is practically exploitable depends on the surrounding system, noise, protocol, implementation, and attacker access. The defensive decision is still straightforward: &lt;strong&gt;when equality of a secret or secret-derived authenticator controls access, use the platform&amp;rsquo;s dedicated constant-time comparison primitive rather than writing the comparison yourself&lt;/strong&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Compare Security Secrets Without Leaking Match Length</title>
      <link>https://nalar.dev/compare-security-secrets-without-leaking-match-length/</link>
      <pubDate>Tue, 08 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/compare-security-secrets-without-leaking-match-length/</guid>
      <description>&lt;p&gt;Applications compare secret values in places that look deceptively simple: message authentication codes, signed-request tags, API tokens, and other authentication material. A normal string or byte equality operator may return as soon as it finds a mismatch. When the compared value is secret, that data-dependent work can create a timing signal about how much of a guess matched.&lt;/p&gt;&#xA;&lt;p&gt;This does not mean every ordinary string comparison is remotely exploitable. Network noise, runtime behaviour, compiler optimisations, rate limits, and the surrounding protocol all affect what an attacker can measure. The defensive lesson is narrower: when equality itself protects a secret or cryptographic authenticator, do not make its comparison time depend on the matching prefix if your platform already provides a hardened comparison primitive.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
