<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Cryptographic Hashing on Nalar</title>
    <link>https://nalar.dev/tags/cryptographic-hashing/</link>
    <description>Recent content in Cryptographic Hashing on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 13 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/cryptographic-hashing/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Canonical Serialization Makes Byte Identity Explicit</title>
      <link>https://nalar.dev/canonical-serialization-makes-byte-identity-explicit/</link>
      <pubDate>Sun, 13 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/canonical-serialization-makes-byte-identity-explicit/</guid>
      <description>&lt;p&gt;Two serialized documents can represent the same application value and still differ byte for byte. An object member can appear in another order. A number can use a different textual form. Unicode text can contain distinct code-point sequences that render alike. Whitespace may be optional. A serializer can make any of these choices while remaining valid for its format.&lt;/p&gt;&#xA;&lt;p&gt;That flexibility is usually harmless when serialization is only a transport boundary. It becomes part of system semantics when bytes are hashed, signed, compared, cached by digest, or used as content addresses. At that point, logical equivalence is not enough. The operation consumes an exact byte sequence.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
