<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>EchoMix</title><link>https://echomix.org/docs/specs/</link><description>Recent content on EchoMix</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 02 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://echomix.org/docs/specs/index.xml" rel="self" type="application/rss+xml"/><item><title>Contact Voucher Protocol Narration</title><link>https://echomix.org/docs/specs/contact_voucher_narration/</link><pubDate>Tue, 02 Jun 2026 00:00:00 +0000</pubDate><guid>https://echomix.org/docs/specs/contact_voucher_narration/</guid><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;The &lt;a href="../contact_voucher/"&gt;voucher spec&lt;/a&gt; was very difficult for me to read and it overloads variable names and doesn&amp;rsquo;t make certain facts explicit enough. I wrote this spec for my own understanding of the design as an implementation guide for myself.&lt;/p&gt;
&lt;h2 id="streams"&gt;Streams&lt;/h2&gt;
&lt;p&gt;There is no separate reply stream. Alice replies on the very same stream Bob used to mint the voucher.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;MessageStream&lt;/strong&gt;: Bob writes; the group reads. This is the stream whose live messages the protocol must protect.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;VoucherStream&lt;/strong&gt;: the rendezvous, derived entirely from the &lt;code&gt;Voucher&lt;/code&gt;. Box 0 holds Bob&amp;rsquo;s &lt;code&gt;VoucherPayload&lt;/code&gt;; box 1 holds Alice&amp;rsquo;s &lt;code&gt;VoucherReply&lt;/code&gt;.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;the group&amp;rsquo;s other streams&lt;/strong&gt;: each existing member has their own MessageStream, just like Bob&amp;rsquo;s.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="stream-objects"&gt;Stream Objects&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;MessageStream&lt;/strong&gt;: &lt;code&gt;.WriteCap&lt;/code&gt; (Bob keeps), &lt;code&gt;.ReadCap&lt;/code&gt; (travels in &lt;code&gt;VoucherPayload&lt;/code&gt;, inside &lt;code&gt;SignedPleaseAdd&lt;/code&gt;).&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;VoucherStream&lt;/strong&gt;: read and write caps derivable by anyone holding the &lt;code&gt;Voucher&lt;/code&gt;.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;VoucherKeypair&lt;/strong&gt;: &lt;code&gt;VoucherSecretKey&lt;/code&gt; (Bob keeps), &lt;code&gt;VoucherPublicKey&lt;/code&gt; (travels in &lt;code&gt;VoucherPayload&lt;/code&gt;). This is the MKEM keypair under which Alice seals the reply to Bob.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="messages"&gt;Messages&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;SignedPleaseAdd&lt;/code&gt; is Bob&amp;rsquo;s signed self-introduction: a serialized &lt;code&gt;PleaseAdd&lt;/code&gt; (his &lt;code&gt;DisplayName&lt;/code&gt; and &lt;code&gt;MessageStream.ReadCap&lt;/code&gt;) plus a signature over it produced by &lt;code&gt;MessageStream.WriteCap&lt;/code&gt;.&lt;/li&gt;
&lt;/ul&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"&gt;&lt;code class="language-go" data-lang="go"&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#75715e"&gt;// PleaseAdd is a member&amp;#39;s request to join, carrying their display name&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#75715e"&gt;// and the read cap that lets others read their messages.&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#66d9ef"&gt;type&lt;/span&gt; &lt;span style="color:#a6e22e"&gt;PleaseAdd&lt;/span&gt; &lt;span style="color:#66d9ef"&gt;struct&lt;/span&gt; {
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &lt;span style="color:#75715e"&gt;// DisplayName is the party&amp;#39;s name to be displayed in chat clients.&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &lt;span style="color:#a6e22e"&gt;DisplayName&lt;/span&gt; &lt;span style="color:#66d9ef"&gt;string&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &lt;span style="color:#75715e"&gt;// UniversalReadCap is the BACAP read cap for this member&amp;#39;s&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &lt;span style="color:#75715e"&gt;// MessageStream, letting others read all messages posted by them.&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &lt;span style="color:#a6e22e"&gt;UniversalReadCap&lt;/span&gt; &lt;span style="color:#f92672"&gt;*&lt;/span&gt;&lt;span style="color:#a6e22e"&gt;bacap&lt;/span&gt;.&lt;span style="color:#a6e22e"&gt;UniversalReadCap&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;}
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#75715e"&gt;// SignedPleaseAdd binds a PleaseAdd to a signature made by the member&amp;#39;s&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#75715e"&gt;// write cap, so any party can verify the name-and-cap binding.&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#66d9ef"&gt;type&lt;/span&gt; &lt;span style="color:#a6e22e"&gt;SignedPleaseAdd&lt;/span&gt; &lt;span style="color:#66d9ef"&gt;struct&lt;/span&gt; {
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &lt;span style="color:#75715e"&gt;// PleaseAdd contains the CBOR serialized PleaseAdd struct.&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &lt;span style="color:#a6e22e"&gt;PleaseAdd&lt;/span&gt; []&lt;span style="color:#66d9ef"&gt;byte&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &lt;span style="color:#75715e"&gt;// Signature contains the cryptographic signature over the PleaseAdd field.&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &lt;span style="color:#a6e22e"&gt;Signature&lt;/span&gt; []&lt;span style="color:#66d9ef"&gt;byte&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;}
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;ul&gt;
&lt;li&gt;&lt;code&gt;WhoReply&lt;/code&gt; := the existing members&amp;rsquo; MessageStream read caps (one or more), so Bob can read everyone already in the group.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;VoucherReply&lt;/code&gt; := &lt;code&gt;WhoReply || VoucherSalt&lt;/code&gt;, MKEM-sealed to &lt;code&gt;VoucherPublicKey&lt;/code&gt; and written to VoucherStream box 1. Box 1 is an ordinary BACAP box, so the payload is BACAP-encrypted as a stream box and then additionally MKEM-encrypted to Bob&amp;rsquo;s &lt;code&gt;VoucherPublicKey&lt;/code&gt;; only Bob, holding &lt;code&gt;VoucherSecretKey&lt;/code&gt;, can open it.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;Introduction&lt;/code&gt; := Bob&amp;rsquo;s display name together with his salt-mutated MessageStream read cap, published to the existing group so the members can read Bob. The group receives the mutated cap directly and never the salt.&lt;/li&gt;
&lt;/ul&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt;VoucherPayload := SignedPleaseAdd || VoucherPublicKey
Voucher := Hash(VoucherPayload)
&lt;/code&gt;&lt;/pre&gt;&lt;h2 id="the-vouchersalt-re-seeding-the-messagestream"&gt;The VoucherSalt: re-seeding the MessageStream&lt;/h2&gt;
&lt;p&gt;&lt;code&gt;VoucherSalt&lt;/code&gt; is the heart of the protocol. It is &lt;strong&gt;not&lt;/strong&gt; a nonce and it does &lt;strong&gt;not&lt;/strong&gt; modify BACAP. It is a value that &lt;strong&gt;replaces the KDF state&lt;/strong&gt; inside a MessageStream&amp;rsquo;s &lt;code&gt;MessageBoxIndex&lt;/code&gt;, which re-seeds the index chain and so moves the stream to a fresh, unpredictable sequence of box IDs. Only two parties ever touch it. Bob mutates his &lt;code&gt;MessageStream.WriteCap&lt;/code&gt; by the salt and writes his real messages at the mutated position. Alice mutates Bob&amp;rsquo;s matching &lt;code&gt;MessageStream.ReadCap&lt;/code&gt; by the same salt &lt;strong&gt;once&lt;/strong&gt;, before she shares it, so writer and readers meet at the mutated position. The group never learns the salt; it only ever receives the already-mutated read cap.&lt;/p&gt;</description></item><item><title>Wire protocol</title><link>https://echomix.org/docs/specs/wire_protocol/</link><pubDate>Mon, 11 May 2026 21:25:36 -0700</pubDate><guid>https://echomix.org/docs/specs/wire_protocol/</guid><description>&lt;div class="article"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h2 id="katzenpost-mix-network-wire-protocol"&gt;&lt;span id="wire_protocol"&gt;&lt;/span&gt;Katzenpost mix network wire protocol&lt;/h2&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="authorgroup"&gt;
&lt;div class="author"&gt;
&lt;h3 id="yawning-angel"&gt;&lt;span class="firstname"&gt;Yawning&lt;/span&gt; &lt;span class="surname"&gt;Angel&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="david-stainton"&gt;&lt;span class="firstname"&gt;David&lt;/span&gt; &lt;span class="surname"&gt;Stainton&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="abstract"&gt;
&lt;p&gt;&lt;strong&gt;Abstract&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;This document defines the Katzenpost Mix Network Wire Protocol for use in all
network communications to, from, and within the Katzenpost Mix Network.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;hr&gt;
&lt;/div&gt;
&lt;div class="toc"&gt;
&lt;p&gt;&lt;strong&gt;Table of Contents&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#conventions-used-in-this-document"&gt;1.1 Conventions Used in This Document&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#wire_protocol_introduction"&gt;1. Introduction&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#key-encapsulation-mechanism"&gt;1.2 Key Encapsulation Mechanism&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#core-protocol"&gt;2. Core Protocol&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#handshake-phase"&gt;2.1 Handshake Phase&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#handshake-authentication"&gt;2.1.1 Handshake Authentication&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#data-transfer-phase"&gt;2.2 Data Transfer Phase&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#predefined-commands"&gt;3. Predefined Commands&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#the-no_op-command"&gt;3.1 The no_op Command&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#the-disconnect-command"&gt;3.2 The disconnect Command&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;</description></item><item><title>Sphinx cryptographic packet format</title><link>https://echomix.org/docs/specs/sphinx_format/</link><pubDate>Mon, 11 May 2026 21:24:41 -0700</pubDate><guid>https://echomix.org/docs/specs/sphinx_format/</guid><description>&lt;div class="article"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h1 id="sphinx-cryptographic-packet-format"&gt;&lt;span id="sphinx"&gt;&lt;/span&gt;Sphinx cryptographic packet format&lt;/h1&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="authorgroup"&gt;
&lt;div class="author"&gt;
&lt;h3 id="yawning-angel"&gt;&lt;span class="firstname"&gt;Yawning&lt;/span&gt; &lt;span class="surname"&gt;Angel&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="george-danezis"&gt;&lt;span class="firstname"&gt;George&lt;/span&gt; &lt;span class="surname"&gt;Danezis&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="claudia-diaz"&gt;&lt;span class="firstname"&gt;Claudia&lt;/span&gt; &lt;span class="surname"&gt;Diaz&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="ania-piotrowska"&gt;&lt;span class="firstname"&gt;Ania&lt;/span&gt; &lt;span class="surname"&gt;Piotrowska&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="david-stainton"&gt;&lt;span class="firstname"&gt;David&lt;/span&gt; &lt;span class="surname"&gt;Stainton&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="abstract"&gt;
&lt;p&gt;&lt;strong&gt;Abstract&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;This document defines the Sphinx cryptographic packet format for decryption mix
networks, and provides a parameterization based around generic cryptographic
primitives types. This document does not introduce any new crypto, but is meant to
serve as an implementation guide.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;hr&gt;
&lt;/div&gt;
&lt;div class="toc"&gt;
&lt;p&gt;&lt;strong&gt;Table of Contents&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#terminology"&gt;Terminology&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#conventions-used-in-this-document"&gt;Conventions Used in This
Document&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#sphinx_introduction"&gt;1. Introduction&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#cryptographic-primitives"&gt;2. Cryptographic Primitives&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#sphinx-key-derivation-function"&gt;2.1 Sphinx Key Derivation Function&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#sphinx-packet-parameters"&gt;3. Sphinx Packet Parameters&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;</description></item><item><title>Sphinx packet replay detection</title><link>https://echomix.org/docs/specs/packet_replay/</link><pubDate>Mon, 11 May 2026 21:23:36 -0700</pubDate><guid>https://echomix.org/docs/specs/packet_replay/</guid><description>&lt;div class="article"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h1 id="sphinx-packet-replay-detection"&gt;&lt;span id="replay"&gt;&lt;/span&gt;Sphinx packet replay detection&lt;/h1&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="authorgroup"&gt;
&lt;div class="author"&gt;
&lt;h3 id="david-stainton"&gt;&lt;span class="firstname"&gt;David&lt;/span&gt; &lt;span class="surname"&gt;Stainton&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="abstract"&gt;
&lt;p&gt;&lt;strong&gt;Abstract&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;This document defines the replay detection for any protocol that uses Sphinx
cryptographic packet format. This document is meant to serve as an implementation
guide and document the existing replay protect for deployed mix networks.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;hr&gt;
&lt;/div&gt;
&lt;div class="toc"&gt;
&lt;p&gt;&lt;strong&gt;Table of Contents&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#terminology"&gt;Terminology&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#d58e95"&gt;Conventions Used in This Document&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#sphinx_replay_detection_introduction"&gt;1. Introduction&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#sphinx-cryptographic-primitives"&gt;2. Sphinx Cryptographic Primitives&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#sphinx-parameter-constants"&gt;2.1 Sphinx Parameter Constants&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#system-overview"&gt;3. System Overview&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#sphinx-packet-replay-cache"&gt;4. Sphinx Packet Replay Cache&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#sphinx-replay-tag-composition"&gt;4.1 Sphinx Replay Tag Composition&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;</description></item><item><title>Public key infrastructure</title><link>https://echomix.org/docs/specs/pki/</link><pubDate>Mon, 11 May 2026 21:21:55 -0700</pubDate><guid>https://echomix.org/docs/specs/pki/</guid><description>&lt;div class="article"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h1 id="public-key-infrastructure"&gt;&lt;span id="pki"&gt;&lt;/span&gt;Public key infrastructure&lt;/h1&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="authorgroup"&gt;
&lt;div class="author"&gt;
&lt;h3 id="yawning-angel"&gt;&lt;span class="firstname"&gt;Yawning&lt;/span&gt; &lt;span class="surname"&gt;Angel&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="claudia-diaz"&gt;&lt;span class="firstname"&gt;Claudia&lt;/span&gt; &lt;span class="surname"&gt;Diaz&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="ania-piotrowska"&gt;&lt;span class="firstname"&gt;Ania&lt;/span&gt; &lt;span class="surname"&gt;Piotrowska&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="david-stainton"&gt;&lt;span class="firstname"&gt;David&lt;/span&gt; &lt;span class="surname"&gt;Stainton&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="masala"&gt;&lt;span class="firstname"&gt;&lt;/span&gt; &lt;span class="surname"&gt;Masala&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="abstract"&gt;
&lt;p&gt;&lt;strong&gt;Abstract&lt;/strong&gt;&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;hr&gt;
&lt;/div&gt;
&lt;div class="toc"&gt;
&lt;p&gt;&lt;strong&gt;Table of Contents&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#terminology"&gt;Terminology&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#conventions-used-in-this-document"&gt;Conventions used in this document&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#pki_introduction"&gt;1. Introduction&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#security-properties-overview"&gt;1.2 Security properties overview&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#differences-from-tor-and-mixminion-directory-authority-systems"&gt;1.3 Differences from Tor and Mixminion directory authority systems&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#overview-of-mix-pki-interaction"&gt;2. Overview of mix PKI interaction&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#pki-protocol-schedule"&gt;2.1 PKI protocol schedule&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#directory-authority-server-schedule"&gt;2.1.1 Directory authority server schedule&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#mix-schedule"&gt;2.1.2 Mix schedule&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#voting-for-consensus-protocol"&gt;3. Voting for consensus protocol&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#protocol-messages"&gt;3.1 Protocol messages&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#mix-descriptor-and-directory-signing"&gt;3.1.1 Mix descriptor and directory signing&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#vote-exchange"&gt;3.2 Vote exchange&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#reveal-exchange"&gt;3.3 Reveal exchange&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;</description></item><item><title>Mix network design</title><link>https://echomix.org/docs/specs/mix_network/</link><pubDate>Mon, 11 May 2026 21:21:06 -0700</pubDate><guid>https://echomix.org/docs/specs/mix_network/</guid><description>&lt;div class="article"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h1 id="mix-network-specification"&gt;&lt;span id="mixspec"&gt;&lt;/span&gt;Mix network specification&lt;/h1&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="authorgroup"&gt;
&lt;div class="author"&gt;
&lt;h3 id="yawning-angel"&gt;&lt;span class="firstname"&gt;Yawning&lt;/span&gt; &lt;span class="surname"&gt;Angel&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="george-danezis"&gt;&lt;span class="firstname"&gt;George&lt;/span&gt; &lt;span class="surname"&gt;Danezis&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="claudia-diaz"&gt;&lt;span class="firstname"&gt;Claudia&lt;/span&gt; &lt;span class="surname"&gt;Diaz&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="ania-piotrowska"&gt;&lt;span class="firstname"&gt;Ania&lt;/span&gt; &lt;span class="surname"&gt;Piotrowska&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="david-stainton"&gt;&lt;span class="firstname"&gt;David&lt;/span&gt; &lt;span class="surname"&gt;Stainton&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="abstract"&gt;
&lt;p&gt;&lt;strong&gt;Abstract&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;This document describes the high level architecture and detailed protocols and
behavior required of mix nodes participating in the Katzenpost Mix Network.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;hr&gt;
&lt;/div&gt;
&lt;div class="toc"&gt;
&lt;p&gt;&lt;strong&gt;Table of Contents&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#terminology"&gt;Terminology&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#d58e162"&gt;Conventions Used in This Document&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#mixnet_introduction"&gt;1. Introduction&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#system-overview"&gt;2. System Overview&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#threat-model"&gt;2.1 Threat Model&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#network-topology"&gt;2.2 Network Topology&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#packet-format-overview"&gt;3. Packet Format Overview&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#sphinx-cryptographic-primitives"&gt;3.1 Sphinx Cryptographic
Primitives&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#sphinx-packet-parameters"&gt;3.2 Sphinx Packet Parameters&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#sphinx-per-hop-routing-information-extensions"&gt;3.3 Sphinx Per-hop
Routing Information Extensions&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#mix-node-operation"&gt;4. Mix Node Operation&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;</description></item><item><title>Mix decoy loop</title><link>https://echomix.org/docs/specs/mix_decoy/</link><pubDate>Mon, 11 May 2026 21:19:15 -0700</pubDate><guid>https://echomix.org/docs/specs/mix_decoy/</guid><description>&lt;div class="article"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h1 id="propagation-of-mix-decoy-loop-statistics"&gt;&lt;span id="decoy"&gt;&lt;/span&gt;Propagation of mix decoy loop statistics&lt;/h1&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="authorgroup"&gt;
&lt;div class="author"&gt;
&lt;h3 id="david-stainton"&gt;&lt;span class="firstname"&gt;David&lt;/span&gt; &lt;span class="surname"&gt;Stainton&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="eva-infeld"&gt;&lt;span class="firstname"&gt;Eva&lt;/span&gt; &lt;span class="surname"&gt;Infeld&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="leif-ryge"&gt;&lt;span class="firstname"&gt;Leif&lt;/span&gt; &lt;span class="surname"&gt;Ryge&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="abstract"&gt;
&lt;p&gt;&lt;strong&gt;Abstract&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;In the context of continuous time mixing strategies such as the memoryless mix
used by Katzenpost, n-1 attacks may use strategic packetloss. Nodes can also fail
for benign reasons. Determining whether or not it’s an n-1 attack is outside the
scope of this work.&lt;/p&gt;
&lt;p&gt;This document describes how we will communicate statistics from mix nodes to mix
network directory authorities which tells them about the packetloss they are
observing.&lt;/p&gt;</description></item><item><title>KEMSphinx</title><link>https://echomix.org/docs/specs/kemsphinx/</link><pubDate>Mon, 11 May 2026 21:18:18 -0700</pubDate><guid>https://echomix.org/docs/specs/kemsphinx/</guid><description>&lt;div class="article"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h1 id="kemsphinx"&gt;&lt;span id="kemsphinx"&gt;&lt;/span&gt;KEMSphinx&lt;/h1&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="authorgroup"&gt;
&lt;div class="author"&gt;
&lt;h3 id="david-stainton"&gt;&lt;span class="firstname"&gt;David&lt;/span&gt; &lt;span class="surname"&gt;Stainton&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="abstract"&gt;
&lt;p&gt;&lt;strong&gt;Abstract&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Here I present a modification of the Sphinx cryptographic packet format that uses
a KEM instead of a NIKE whilst preserving the properties of bitwise unlinkability,
constant packet size and route length hiding.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;hr&gt;
&lt;/div&gt;
&lt;div class="toc"&gt;
&lt;p&gt;&lt;strong&gt;Table of Contents&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#kemsphinx_introduction"&gt;1. Introduction&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#post-quantum-hybrid-kem"&gt;2. Post Quantum Hybrid KEM&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#nike-to-kem-adapter"&gt;2.1 NIKE to KEM adapter&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#kem-combiner"&gt;2.2 KEM Combiner&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#kemsphinx-header-design"&gt;3. KEMSphinx Header Design&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#kemsphinx-unwrap-operation"&gt;4. KEMSphinx Unwrap Operation&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#acknowledgments"&gt;Acknowledgments&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#appendix-a.-references"&gt;References&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;/div&gt;
&lt;div class="section"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h2 id="1-introduction"&gt;&lt;span id="kemsphinx_introduction"&gt;&lt;/span&gt;1. Introduction&lt;/h2&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;p&gt;We’ll express our KEM Sphinx header in pseudo code. The Sphinx body will be exactly
the same as &lt;a href="#SPHINXSPEC" class="xref"&gt;the section called “References”&lt;/a&gt; Our basic KEM API has three functions:&lt;/p&gt;</description></item><item><title>Contact Voucher Design</title><link>https://echomix.org/docs/specs/contact_voucher/</link><pubDate>Mon, 11 May 2026 21:16:30 -0700</pubDate><guid>https://echomix.org/docs/specs/contact_voucher/</guid><description>&lt;div class="article"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h1 id="contact-voucher-design"&gt;&lt;span id="voucher"&gt;&lt;/span&gt;Contact Voucher Design&lt;/h1&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="authorgroup"&gt;
&lt;div class="author"&gt;
&lt;h3 id="threebit-hacker"&gt;&lt;span class="firstname"&gt;Threebit&lt;/span&gt; &lt;span class="surname"&gt;Hacker&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="leif-ryge"&gt;&lt;span class="firstname"&gt;Leif&lt;/span&gt; &lt;span class="surname"&gt;Ryge&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="abstract"&gt;
&lt;p&gt;&lt;strong&gt;Abstract&lt;/strong&gt;&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;hr&gt;
&lt;/div&gt;
&lt;div class="toc"&gt;
&lt;p&gt;&lt;strong&gt;Table of Contents&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#d58e43"&gt;Voucher Design&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#d58e76"&gt;Self-authenticating BACAP payload&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;/div&gt;
&lt;div class="section"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h2 id="voucher-design"&gt;&lt;span id="d58e43"&gt;&lt;/span&gt;Voucher Design&lt;/h2&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;p&gt;In order to join or initiate a conversation, participants need to
exchange cryptographic key material. To address this problem we have
a slightly unusual design: Contact vouchers.&lt;/p&gt;
&lt;p&gt;In many systems, invites to conversations flow from an existing
member of the conversation to the user being invited. In our
&amp;ldquo;Contact Voucher&amp;rdquo; protocol this flow is reversed: A member
wishing to join a conversation hands a &amp;ldquo;Contact Voucher&amp;rdquo;
(out of band) to the existing member, who then inducts the new
member into the group.&lt;/p&gt;</description></item><item><title>Certificate format</title><link>https://echomix.org/docs/specs/certificate_format/</link><pubDate>Mon, 11 May 2026 21:14:56 -0700</pubDate><guid>https://echomix.org/docs/specs/certificate_format/</guid><description>&lt;div class="article"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h1 id="certificate-format"&gt;&lt;span id="certificate"&gt;&lt;/span&gt;Certificate format&lt;/h1&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="authorgroup"&gt;
&lt;div class="author"&gt;
&lt;h3 id="david-stainton"&gt;&lt;span class="firstname"&gt;David&lt;/span&gt; &lt;span class="surname"&gt;Stainton&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="abstract"&gt;
&lt;p&gt;&lt;strong&gt;Abstract&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;This document proposes a certificate format that Katzenpost mix server, directory
authority server and clients will use.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;hr&gt;
&lt;/div&gt;
&lt;div class="toc"&gt;
&lt;p&gt;&lt;strong&gt;Table of Contents&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#terminology"&gt;Terminology&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#conventions-used-in-this-document"&gt;Conventions Used in This Document&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#certificate_introduction"&gt;1. Introduction&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#document-format"&gt;1.1. Document Format&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#certificate-types"&gt;1.2 Certificate Types&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#certificate-key-types"&gt;1.3. Certificate Key Types&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#golang-api"&gt;2. Golang API&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#acknowledgments"&gt;Acknowledgments&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#appendix-a.-references"&gt;References&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;/div&gt;
&lt;div class="section"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h2 id="terminology"&gt;&lt;span id="terminology"&gt;&lt;/span&gt;Terminology&lt;/h2&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;p&gt;The following terms are used in this specification.&lt;/p&gt;
&lt;div class="variablelist"&gt;
&lt;p&gt;&lt;span class="term"&gt;&lt;/span&gt;&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div class="section"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h2 id="conventions-used-in-this-document"&gt;&lt;span id="conventions-used-in-this-document"&gt;&lt;/span&gt;Conventions Used in This Document&lt;/h2&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;p&gt;The key words &lt;span class="quote"&gt;“&lt;span class="quote"&gt;MUST&lt;/span&gt;”&lt;/span&gt;, &lt;span class="quote"&gt;“&lt;span class="quote"&gt;MUST NOT&lt;/span&gt;”&lt;/span&gt;,
&lt;span class="quote"&gt;“&lt;span class="quote"&gt;REQUIRED&lt;/span&gt;”&lt;/span&gt;, &lt;span class="quote"&gt;“&lt;span class="quote"&gt;SHALL&lt;/span&gt;”&lt;/span&gt;, &lt;span class="quote"&gt;“&lt;span class="quote"&gt;SHALL NOT&lt;/span&gt;”&lt;/span&gt;,
&lt;span class="quote"&gt;“&lt;span class="quote"&gt;SHOULD&lt;/span&gt;”&lt;/span&gt;, &lt;span class="quote"&gt;“&lt;span class="quote"&gt;SHOULD NOT&lt;/span&gt;”&lt;/span&gt;, &lt;span class="quote"&gt;“&lt;span class="quote"&gt;RECOMMENDED&lt;/span&gt;”&lt;/span&gt;,
&lt;span class="quote"&gt;“&lt;span class="quote"&gt;MAY&lt;/span&gt;”&lt;/span&gt;, and &lt;span class="quote"&gt;“&lt;span class="quote"&gt;OPTIONAL&lt;/span&gt;”&lt;/span&gt; in this document are to be
interpreted as described in &lt;a href="#RFC2119" class="link"&gt;RFC2119&lt;/a&gt;.&lt;/p&gt;</description></item><item><title>Provider-side autoresponder extension</title><link>https://echomix.org/docs/specs/autoresponder/</link><pubDate>Mon, 11 May 2026 21:09:52 -0700</pubDate><guid>https://echomix.org/docs/specs/autoresponder/</guid><description>&lt;div class="article"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h1 id="provider-side-autoresponder-extension-kaetzchen"&gt;&lt;span id="autoresponder"&gt;&lt;/span&gt;Provider-side autoresponder extension (Kaetzchen)&lt;/h1&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="authorgroup"&gt;
&lt;div class="author"&gt;
&lt;h3 id="yawning-angel"&gt;&lt;span class="firstname"&gt;Yawning&lt;/span&gt; &lt;span class="surname"&gt;Angel&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="kali-kaneko"&gt;&lt;span class="firstname"&gt;Kali&lt;/span&gt; &lt;span class="surname"&gt;Kaneko&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="david-stainton"&gt;&lt;span class="firstname"&gt;David&lt;/span&gt; &lt;span class="surname"&gt;Stainton&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="abstract"&gt;
&lt;p&gt;&lt;strong&gt;Abstract&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;This interface is meant to provide support for various autoresponder agents
&lt;span class="quote"&gt;“&lt;span class="quote"&gt;Kaetzchen&lt;/span&gt;”&lt;/span&gt; that run on Katzenpost provider instances, thus
bypassing the need to run a discrete client instance to provide functionality. The
use-cases for such agents include, but are not limited to, user identity key lookup,
a discard address, and a loop-back responder for the purpose of cover
traffic.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;hr&gt;
&lt;/div&gt;
&lt;div class="toc"&gt;
&lt;p&gt;&lt;strong&gt;Table of Contents&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#d58e50"&gt;Conventions Used in This Document&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;</description></item><item><title>Glossary</title><link>https://echomix.org/docs/specs/glossary/</link><pubDate>Mon, 11 May 2026 21:17:28 -0700</pubDate><guid>https://echomix.org/docs/specs/glossary/</guid><description>&lt;div class="article"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h1 id="glossary"&gt;&lt;span id="glossary"&gt;&lt;/span&gt;Glossary&lt;/h1&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;hr&gt;
&lt;/div&gt;
&lt;div class="variablelist"&gt;
&lt;p&gt;&lt;span class="term"&gt;&lt;span class="bold"&gt;&lt;strong&gt;BlockSphinxPlaintext&lt;/strong&gt;&lt;/span&gt;&lt;/span&gt;&lt;br&gt;
The payload structure which is encapsulated by the Sphinx body.&lt;/p&gt;
&lt;p&gt;&lt;span class="term"&gt;&lt;span class="bold"&gt;&lt;strong&gt;classes of traffic&lt;/strong&gt;&lt;/span&gt;&lt;/span&gt;&lt;br&gt;
We distinguish the following classes of traffic:&lt;/p&gt;
&lt;div class="itemizedlist"&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;SURB Replies (also sometimes referred to as ACKs)&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Forward messages&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;/div&gt;
&lt;p&gt;&lt;span class="term"&gt;&lt;span class="bold"&gt;&lt;strong&gt;client&lt;/strong&gt;&lt;/span&gt;&lt;/span&gt;&lt;br&gt;
Software run by the User on its local device to participate in the Mixnet.
Again let us reiterate that a client is not considered a &amp;ldquo;node in the
network&amp;rdquo; at the level of analysis where we are discussing the core mixnet
protocol in this here document.&lt;/p&gt;</description></item><item><title>References</title><link>https://echomix.org/docs/specs/references/</link><pubDate>Mon, 11 May 2026 21:22:38 -0700</pubDate><guid>https://echomix.org/docs/specs/references/</guid><description>&lt;div class="article"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h1 id="references"&gt;&lt;span id="references"&gt;&lt;/span&gt;References&lt;/h1&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;hr&gt;
&lt;/div&gt;
&lt;p&gt;&lt;span id="AB96"&gt;&lt;/span&gt;&lt;span class="bold"&gt;&lt;strong&gt;AB96&lt;/strong&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;Anderson, R., Biham, E., &lt;span class="quote"&gt;“&lt;span class="quote"&gt;Two Practical and Provably Secure Block Ciphers: BEAR and LION&lt;/span&gt;”&lt;/span&gt;, 1996.&lt;/p&gt;
&lt;p&gt;&lt;span id="AEZV5"&gt;&lt;/span&gt;&lt;span class="bold"&gt;&lt;strong&gt;AEZV5&lt;/strong&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;Hoang, V., Krovetz, T., Rogaway, P., &lt;span class="quote"&gt;“&lt;span class="quote"&gt;AEZ v5: Authenticated Encryption by Enciphering&lt;/span&gt;”&lt;/span&gt;, March 2017,
&lt;a href="http://web.cs.ucdavis.edu/~rogaway/aez/aez.pdf" class="link" target="_top"&gt;&lt;a href="http://web.cs.ucdavis.edu/~rogaway/aez/aez.pdf"&gt;http://web.cs.ucdavis.edu/~rogaway/aez/aez.pdf&lt;/a&gt;&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;span id="BRIDGING"&gt;&lt;/span&gt;&lt;span class="bold"&gt;&lt;strong&gt;BRIDGING&lt;/strong&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;Danezis, G., Syverson, P., &lt;span class="quote"&gt;“&lt;span class="quote"&gt;Bridging and Fingerprinting: Epistemic Attacks
on Route Selection&lt;/span&gt;”&lt;/span&gt;, Proceedings of PETS 2008, Leuven, Belgium,
July 2008, &lt;a href="https://www.freehaven.net/anonbib/cache/danezis-pet2008.pdf" class="link" target="_top"&gt;&lt;a href="https://www.freehaven.net/anonbib/cache/danezis-pet2008.pdf"&gt;https://www.freehaven.net/anonbib/cache/danezis-pet2008.pdf&lt;/a&gt;&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;span id="COMPULS05"&gt;&lt;/span&gt;&lt;span class="bold"&gt;&lt;strong&gt;COMPULS05&lt;/strong&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;Danezis, G., Clulow, J., &lt;span class="quote"&gt;“&lt;span class="quote"&gt;Compulsion Resistant Anonymous Communications&lt;/span&gt;”&lt;/span&gt;,
Proceedings of Information Hiding Workshop, June 2005,
&lt;a href="https://www.freehaven.net/anonbib/cache/ih05-danezisclulow.pdf" class="link" target="_top"&gt;&lt;a href="https://www.freehaven.net/anonbib/cache/ih05-danezisclulow.pdf"&gt;https://www.freehaven.net/anonbib/cache/ih05-danezisclulow.pdf&lt;/a&gt;&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;span id="ED25519"&gt;&lt;/span&gt;&lt;span class="bold"&gt;&lt;strong&gt;ED25519&lt;/strong&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;a href="https://www.rfc-editor.org/rfc/rfc8032" class="link" target="_top"&gt;&lt;a href="https://www.rfc-editor.org/rfc/rfc8032"&gt;https://www.rfc-editor.org/rfc/rfc8032&lt;/a&gt;&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;span id="FINGERPRINTING"&gt;&lt;/span&gt;&lt;span class="bold"&gt;&lt;strong&gt;FINGERPRINTING&lt;/strong&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;Danezis, G., Clayton, R., &lt;span class="quote"&gt;“&lt;span class="quote"&gt;Route Finger printing in Anonymous
Communications&lt;/span&gt;”&lt;/span&gt;,
&lt;a href="https://www.cl.cam.ac.uk/~rnc1/anonroute.pdf" class="link" target="_top"&gt;&lt;a href="https://www.cl.cam.ac.uk/~rnc1/anonroute.pdf"&gt;https://www.cl.cam.ac.uk/~rnc1/anonroute.pdf&lt;/a&gt;&lt;/a&gt;.&lt;/p&gt;</description></item><item><title>Group chat</title><link>https://echomix.org/docs/specs/group_chat/</link><pubDate>Mon, 11 May 2026 09:45:35 -0700</pubDate><guid>https://echomix.org/docs/specs/group_chat/</guid><description>&lt;div class="article"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h1 id="katzenpost-group-chat-design"&gt;&lt;span id="group_chat"&gt;&lt;/span&gt;Katzenpost Group Chat Design&lt;/h1&gt;
&lt;/div&gt;
&lt;div&gt;
&lt;div class="authorgroup"&gt;
&lt;div class="author"&gt;
&lt;h3 id="threebit-hacker"&gt;&lt;span class="firstname"&gt;Threebit&lt;/span&gt; &lt;span class="surname"&gt;Hacker&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;div class="author"&gt;
&lt;h3 id="david-stainton"&gt;&lt;span class="firstname"&gt;David&lt;/span&gt; &lt;span class="surname"&gt;Stainton&lt;/span&gt;&lt;/h3&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;hr&gt;
&lt;/div&gt;
&lt;div class="toc"&gt;
&lt;p&gt;&lt;strong&gt;Table of Contents&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#d58e44"&gt;Prerequisites&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#d58e64"&gt;Introduction&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#d58e102"&gt;Group Chat Message Types&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#d58e165"&gt;Protocol Flow&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span class="section"&gt;&lt;a href="#d58e239"&gt;Addenda&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;/div&gt;
&lt;div class="section"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h2 id="prerequisites"&gt;&lt;span id="d58e44"&gt;&lt;/span&gt;Prerequisites&lt;/h2&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;p&gt;This design specification is dependent on the BACAP and Pigeonhole protocol designs
from
our paper &lt;a href="https://arxiv.org/abs/2501.02933" class="link" target="_top"&gt;Echomix: A Strong Anonymity
System with Messaging&lt;/a&gt;, which describes&lt;/p&gt;
&lt;div class="itemizedlist"&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;the BACAP (blinded and capability) in section 4 and&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;the Pigeonhole protocol in section 5.&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;/div&gt;
&lt;p&gt;The &lt;a href="https://github.com/katzenpost/hpqc/blob/main/bacap/bacap.go" class="link" target="_top"&gt;source
code&lt;/a&gt; and &lt;a href="https://github.com/katzenpost/hpqc/blob/main/bacap/bacap.go" class="link" target="_top"&gt;API docs&lt;/a&gt; for
BACAP are available on pkg.go.dev.&lt;/p&gt;
&lt;/div&gt;
&lt;div class="section"&gt;
&lt;div class="titlepage"&gt;
&lt;div&gt;
&lt;div&gt;
&lt;h2 id="introduction"&gt;&lt;span id="d58e64"&gt;&lt;/span&gt;Introduction&lt;/h2&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;p&gt;The Pigeonhole protocol establishes anonymous cryptographic communication channels
which
have a &lt;span class="emphasis"&gt;&lt;em&gt;readcap&lt;/em&gt;&lt;/span&gt; (read capability) and a &lt;span class="emphasis"&gt;&lt;em&gt;writecap&lt;/em&gt;&lt;/span&gt;
(write capability). For example, if Alice and Bob want to communicate, they can each
create
their own Pigeonhole/BACAP channels and exchange readcaps on those channels. Now when
Bob
writes to his channel, Alice can read those messages because she has Bob&amp;rsquo;s readcap.
Likewise,
when Alice writes to her channel, Bob can read those messages because he has Alice&amp;rsquo;s
readcap.
This is the most basic construction using BACAP and Pigeonhole.&lt;/p&gt;</description></item><item><title/><link>https://echomix.org/docs/specs/thin_client.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://echomix.org/docs/specs/thin_client.html</guid><description>&lt;h1 id="katzenpost-thin-client-design"&gt;Katzenpost Thin Client Design&lt;/h1&gt;
&lt;h1 id="1-introduction"&gt;1. Introduction&lt;/h1&gt;
&lt;p&gt;A Katzenpost mixnet client has several responsibilities at minimum:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;compose Sphinx packets&lt;/li&gt;
&lt;li&gt;decrypt SURB replies&lt;/li&gt;
&lt;li&gt;send and receive Noise protocol messages&lt;/li&gt;
&lt;li&gt;keep up to date with the latest PKI document&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;This document describes the design of the new Katzenpost mix network
client known as client2. In particular we discuss it&amp;rsquo;s multiplexing and
privilege separation design elements as well as the protocol used by the
thin client library.&lt;/p&gt;</description></item><item><title/><link>https://echomix.org/docs/specs/pigeonhole/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://echomix.org/docs/specs/pigeonhole/</guid><description>&lt;h1 id="pigeonhole-protocol-design-specification"&gt;Pigeonhole Protocol Design Specification&lt;/h1&gt;
&lt;h1 id="abstract"&gt;Abstract&lt;/h1&gt;
&lt;p&gt;In this specification we describe the components and protocols that
compose Pigeonhole scattered storage. We define the behavior of
communication clients that send and retrieve individual messages,
BACAP streams, and AllOrNothing streams. Client actions are mediated
through courier services that interact with storage replicas.&lt;/p&gt;
&lt;h1 id="introduction"&gt;Introduction&lt;/h1&gt;
&lt;p&gt;Pigeonhole scattered storage enables persistent anonymous
communication in which participants experience a coherent sequence of
messages or a continuous data stream, but where user relationships and
relations between data blocks remain unlinkable not only from the
perspective of third-party observers, but also from that of the mixnet
components. This latter attribute provides resilience against
deanonymization by compromised mixnet nodes.&lt;/p&gt;</description></item></channel></rss>