k1 for ffff, diagrams int ext

4 files changed, 107 insertions, 80 deletions

diff --git a/templates/index.html b/templates/index.html
index accbca7..e864b19 100644
--- a/templates/index.html
+++ b/templates/index.html
@@ -16,13 +16,13 @@
                 <span> at </span><a href="/">cyfraeviolae.org</a>
             </div>
             <div class="crumbs">
-                <a href="/git/forbidden-salamanders">source code</a>
-                <span class="sep"> · </span>
                 <a href="/forbidden-salamanders/key-commitment">key commitment</a>
                 <span class="sep"> · </span>
                 <a href="/forbidden-salamanders/nonce-reuse">nonce reuse</a>
                 <span class="sep"> · </span>
                 <a href="/forbidden-salamanders/mac-truncation">mac truncation</a>
+                <span class="sep"> · </span>
+                <a href="/git/forbidden-salamanders">source code</a>
             </div>
         </div>
 		<p>
@@ -76,7 +76,7 @@
 					m = \alpha^{128}+\alpha^7 + \alpha^2 + \alpha + 1
 				\]
 				\[
-					\mathbb{K} = \mathbb{F}(2^{128})/m.
+                    \mathbb{K} = \mathbb{F}_{2^{128}}/m.
 				\]
 			</p>
 			<p>
@@ -84,7 +84,7 @@
 				interpreted as the set of polynomials with coefficients in \(\mathbb{F}_2\)
 				of degree less than \(128\). Multiplication
 				is performed modulo \(m\). This field is of characteristic 2;
-				e.g., \((\alpha^5 + 1)+(\alpha^5 + 1) = 0\).
+				e.g., \(2=0\), \(a=-a\), \((\alpha^5 + 1)+(\alpha^5 + 1) = 0\).
 			</p>
 			<p>
 				We interpret 16-byte blocks as elements in \(\mathbb{K}\)
diff --git a/templates/key-commitment.html b/templates/key-commitment.html
index ab72df2..af1e656 100644
--- a/templates/key-commitment.html
+++ b/templates/key-commitment.html
@@ -16,13 +16,13 @@
                 <span> at </span><a href="/">cyfraeviolae.org</a>
             </div>
             <div class="crumbs">
-                <a href="/git/forbidden-salamanders">source code</a>
-                <span class="sep"> · </span>
 				<a href="/forbidden-salamanders/key-commitment"><strong>key commitment</strong></a>
                 <span class="sep"> · </span>
                 <a href="/forbidden-salamanders/nonce-reuse">nonce reuse</a>
                 <span class="sep"> · </span>
                 <a href="/forbidden-salamanders/mac-truncation">mac truncation</a>
+                <span class="sep"> · </span>
+                <a href="/git/forbidden-salamanders">source code</a>
             </div>
         </div>
         <p>
@@ -79,17 +79,17 @@
 				key, it will look identical to the BMP file.
 			</em></div>
 
-		<p>
-		Key 1: <code>5c3cb198432b0903e58de9c9647bd241</code>
-		<br>
-		Key 2: <code>df923ae8976230008a081d23205d7a4f</code>
-		<br>
-		Nonce: <code>4a4f5247454c424f52474553</code>
-		</p>
+			<p>
+			Key 1: <code>8007941455b5af579bb12fff92ef31a3</code>
+			<br>
+			Key 2: <code>14ef746e8b1792e52b1d22ef124fae97</code>
+			<br>
+			Nonce: <code>4a4f5247454c424f52474553</code>
+			</p>
 		<br>
 
             <div>
-				<button type="submit">Download polyglot ciphertext</button>
+				<button type="submit">Download ciphertext</button>
             </div>
         </form>
 		<form action="/forbidden-salamanders/key-commitment" method="get">
@@ -99,35 +99,17 @@
 		</form>
 		<p>
             You can test your ciphertext with Go. Run the following in a shell,
-            then try opening <code>first.jpg</code> and <code>second.bmp</code>
-            in an image viewer.
+            then open <code>/tmp/polyglot-first.jpg</code> and <code>/tmp/polyglot-second.bmp</code>
+            in an image viewer. You may need to alter the path of <code>polyglot.enc</code> to reflect
+            your download directory.
 		</p>
-		<details>
-			<summary>
-                Test script.
-			</summary>
-<pre style="font-size: small">
-TEMP="$(mktemp).go"
-cat &gt; "$TEMP" &lt;&lt;EOF
-package main
-import ("crypto/aes"; "crypto/cipher"; "encoding/hex"; "os")
-func main() {
-  var key, nonce, ciphertext, plaintext []byte; var block cipher.Block; var aesgcm cipher.AEAD; var err error
-  if len(os.Args) &lt; 4 { panic("usage: go run salamander.go <key> <nonce> <ciphertext-filename>") }
-  if key, err = hex.DecodeString(os.Args[1]); err != nil { panic(err.Error()) }
-  if nonce, err = hex.DecodeString(os.Args[2]); err != nil { panic(err.Error()) }
-  if ciphertext, err = os.ReadFile(os.Args[3]); err != nil { panic(err.Error()) }
-  if block, err = aes.NewCipher(key); err != nil { panic(err.Error()) }
-  if aesgcm, err = cipher.NewGCM(block); err != nil { panic(err.Error()) }
-  if plaintext, err = aesgcm.Open(nil, nonce, ciphertext, nil); err != nil { panic(err.Error()) }
-  if _, err = os.Stdout.Write(plaintext); err != nil { panic(err.Error()) }
-}
-EOF
-go run "$TEMP" 5c3cb198432b0903e58de9c9647bd241 4a4f5247454c424f52474553 polyglot.enc &gt; first.jpg
-go run "$TEMP" df923ae8976230008a081d23205d7a4f 4a4f5247454c424f52474553 polyglot.enc &gt; second.bmp
+<pre class="demo">
+curl -L -o /tmp/decrypt-aes-gcm.go https://cyfraeviolae.org/forbidden-salamanders/static/decrypt-aes-gcm.go
+go build -o /tmp/decrypt-aes-gcm /tmp/decrypt-aes-gcm.go
+&lt; polyglot.enc /tmp/decrypt-aes-gcm 5c3cb198432b0903e58de9c9647bd241 4a4f5247454c424f52474553 &gt; /tmp/polyglot-first.jpg
+&lt; polyglot.enc /tmp/decrypt-aes-gcm df923ae8976230008a081d23205d7a4f 4a4f5247454c424f52474553 &gt; /tmp/polyglot-second.bmp
 </pre>
-		</details>
-		<details>
+		<etails>
 			<summary>
                 Attack outline.
 			</summary>
@@ -135,6 +117,7 @@ go run "$TEMP" df923ae8976230008a081d23205d7a4f 4a4f5247454c424f52474553 polyglo
             This attack was shown by Yevgeniy Dodis, Paul Grubbs, Thomas Ristenpart, and Joanne Woodage
             in <a href="https://eprint.iacr.org/2019/016">Fast Message Franking: From Invisible Salamanders to Encryptment</a>.
         </p>
+        <h4>Colliding MACs</h4>
         <p>
             First, we will describe a general strategy to create a ciphertext that yields the same MAC
             with two different keys. Then we will show how to construct a ciphertext that yields
@@ -174,67 +157,111 @@ go run "$TEMP" df923ae8976230008a081d23205d7a4f 4a4f5247454c424f52474553 polyglo
             Note that the choice to place the extra block in the final position was arbitrary. For the attack below we will instead need
             to change the penultimate block rather than adding a block; the computation is similar.
         </p>
+        <h4>Magic Bytes</h4>
         <p>
             For the next phase, we construct a ciphertext that decrypts to a valid JPEG under one key and a valid BMP under another.
+            Recall that the ciphertext of AES-GCM, as in AES-CTR, is computed by taking the XOR of the keystream and the message. The keystream
+            is computed from the cipher key and the nonce.
+        </p>
+        <p>
             The basic strategy is to place the JPEG bytes and BMP bytes at different locations, carefully arranging it so
             each parser will ignore the other data for the file. JPEG files can include comments, in which we will include the
             BMP data. The BMP parser will stop reading as soon as the indicated length of the BMP has been read, after which
             we will include the JPEG data. In each decrypted file, the data for the other image will be scrambled as we are using
-            a different key, but it will not matter as the garbage data will be in a location that is ignored by the image parser.
+            a different key, but it will not matter as the junk data will be in a location that is ignored by the image parser.
+        </p>
+        <p>
+        All JPEG files start with the magic bytes \(\mathtt{ffd8}\) and end
+        with \(\mathtt{ffd9}\). We will place a JPEG comment immediately
+        after the initial magic bytes, which is indicated by \(\mathtt{fffe}\) and is followed by a 2-byte big-endian encoding of the comment length \(J\).
+            Let \(J_i\) indicate the \(i\)th byte of \(J\); \(J_0\) being the least significant byte.
         </p>
         <p>
-            All JPEG files start with the magic bytes <code>ffd8</code> and end
-            with <code>ffd9</code>. We will place a JPEG comment immediately
-            after the initial magic bytes, which is indicated by <code>fffe</code> and is followed by a 2-byte big-endian encoding of the comment length.
-            All BMP files start with the magic bytes <code>424d</code> followed by a 4-byte little-endian encoding of the file length.
+            All BMP files start with the magic bytes \(\mathtt{424d}\) followed by a 4-byte little-endian encoding of the file length.
+            Because we need the BMP file to fit inside the JPEG comment, we set
+            \[
+                \begin{array}{|c|c|}\hline
+                & 0 & 1 & 2 & 3 & 4 & 5 & \ldots & -2 & -1 \\\hline
+                \mathsf{JPEG} & \mathtt{ff} & \mathtt{d8} & \mathtt{ff} & \mathtt{fe} & J_1 & J_0 & \ldots & \mathtt{ff} & \mathtt{d9} \\
+                \mathsf{BMP} & \mathtt{42} & \mathtt{4d} & J_0 & J_1 & \mathtt{00} & \mathtt{00} & \ldots & & \\\hline
+                \end{array}
+            \]
         </p>
         <p>
-            Because the JPEG comment has a maximum length, our BMP file will need to be less than <code>ffff=65536</code> bytes.
-            Thus, we desire the JPEG file to start with <code>ffd8 fffe ffff</code> and the BMP file to start with <code>424d wxyz 0000</code>,
-            where <code>wxyz</code> is the actual length of our BMP file.
+            In addition to the file length at the beginning, BMP files also
+            include the size of the color array (the pixels of the image) in
+            the initial metadata. BMP parsers ignore any data after the color
+            array is supposed to be over, even if the file length has not been
+            exhausted yet. That means we can set \(J=\mathtt{ffff}=65536\), and the
+            resulting header will be valid for any BMP file less than \(J\) bytes.
         </p>
         <p>
-            To make it easier, we will only require the first five bytes to match; we can modify ciphertext afterwards to satisfy the final
-            byte of the BMP header. The final byte of the JPEG header will be arbitrary, but this is the least significant part of the
-            comment length, so we will restrict our BMP file length to less than <code>ff00=65280</code> bytes.
+            Since these headers must be in the same location at the start of the file,
+            we search for two keys \(k_1, k_2\) and a nonce \(n\) such that
+            \[ \operatorname{AES-GCTR}(k_1, n, \mathtt{ffd8fffeffff}) = \operatorname{AES-GCTR}(k_2, n, \mathtt{424dffff0000}), \]
+            where \(\operatorname{AES-GCTR}\) returns the ciphertext portion of \(\operatorname{AES-GCM}\) but not the MAC.
         </p>
         <p>
-            Since these must be in the same location at the start of the file,
-            we will need to brute-force search for two keys \(k_1, k_2\) and a nonce that
-            encrypt to the same ciphertext. The easiest way to do this is via a
+            The easiest way to do this is via a
             birthday attack: fix an arbitrary nonce, then generate random keys
             for both the JPEG header and the BMP header. Encrypt each and store
-            them in a lookup table. Repeat until two keys are found that
-            encrypt their respective headers to the same ciphertext bytes.
+            the ciphertext in a lookup table. Repeat until two keys are found that
+            encrypt their respective headers to the same ciphertext bytes. The search
+            takes less than a minute on a desktop computer.
         </p>
         <p>
-            To the ciphertext header, add the encryption of the BMP file
-            (without the header) under \(k_2\), then pad with arbitrary data to reach the end of the JPEG comment (this will be ignored by the BMP
-            parser, which has already finished reading the file). After the
-            JPEG comment is over, add the encryption of the JPEG file (without the header and final magic bytes) under
-            \(k_1\).
+            We have now computed the ciphertext header \(C_{H}\) and two keys
+            which will decrypt it to the correct header bytes for both files.
+            Note that \(C_{H}\) only depends on the <em>maximum</em> size of
+            the BMP file, and thus can be precomputed.  The remainder of the
+            attack that depends on the specific images is very fast.
         </p>
+        <h4>Finishing the Polyglot</h4>
         <p>
-            Finally, add two more bytes of ciphertext that will make the final two
-            bytes of the JPEG file into the appropriate final magic bytes
-            <code>ffd9</code>.
+			As explained before, we place the BMP bytes in the JPEG comment,
+			add padding to finish the comment, and add the JPEG bytes after the comment is over.
+            Below we show the structure of the ciphertext. \(\downarrow\) indicates
+            that this part of the ciphertext is the encryption of the BMP cells under \(k_2\), and similarly \(\uparrow\)
+            indicates the encryption of the JPEG cells under \(k_1\).
+            \[
+                \begin{array}{|c|c|}\hline
+				\mathsf{JPEG} && & \mathtt{00}^{J-\vert \textrm{BMP}\vert} & \textrm{JPEG} & \mathtt{ffd9} \\
+                C & C_H & \downarrow & \uparrow & \uparrow & \uparrow\\
+                \mathsf{BMP} && \textrm{BMP} & & & \\\hline
+                \end{array}
+            \]
+        </p>
+        <p>
+            Here, \(\textrm{JPEG}\) is the bytes of the JPEG file without the initial and final magic bytes,
+            and similarly \(\textrm{BMP}\) is the bytes of the BMP file without the initial magic bytes.
         </p>
         <p>
             These ciphertexts do not have the same MAC yet. If we tried to use
             the strategy outlined at the beginning where we add an extra block
-            at the end, the JPEG file would no longer end in <code>ffd9</code>
-            and thus would be invalid. Instead, we need to modify it to change
-            the penultimate block.
+            at the end, the JPEG file would no longer end in \(\mathtt{ffd9}\)
+            and would be invalid. Instead, we modify it to change
+            the penultimate block. The collision algorithm will result in a
+            ciphertext block \(X\).
+        </p>
+        <p>
+            However, we don't want any data from the penultimate block to
+            corrupt our JPEG image. After \(\textrm{JPEG}\) ends, we start
+            another comment that will include the penultimate block, hiding it
+            from the parser. Care must be taken to ensure the penultimate block
+            is really on a block boundary. For AES-GCM, the block size is 16 bytes.
         </p>
         <p>
-            However, we don't want any data from the penultimate block to show
-            up in our JPEG image. Thus, after the JPEG file data ends, we start
-            another comment that will extend until the penultimate block,
-            hiding it from the parser. Care must be taken to ensure the
-            penultimate block is really on a block boundary (the comment can be
-            padded to increase the length if necessary). After this second
-            comment will appear the final magic bytes <code>ffd9</code> as
-            desired.
+            Below is the final structure of the polyglot ciphertext.
+            \[
+            J' = 16 - (6 + J + \vert \textrm{JPEG} \vert + 4) \pmod{16}
+            \]
+            \[
+                \begin{array}{|c|c|}\hline
+				\mathsf{JPEG} && & \mathtt{00}^{J-\vert \textrm{BMP}\vert} & \mathrm{JPEG} & \mathtt{fffe} & J' & \mathtt{00}^{J'} &  & \mathtt{00}^{14} & \mathtt{ffd9} \\
+                C & C_{H} & \downarrow & \uparrow & \uparrow & \uparrow & \uparrow & \uparrow & X & \uparrow & \uparrow \\
+                \mathsf{BMP} && \textrm{BMP} & & \\\hline
+                \end{array}
+            \]
         </p>
         </details>
 		<details>
diff --git a/templates/mac-truncation.html b/templates/mac-truncation.html
index 1cbd629..9b36de9 100644
--- a/templates/mac-truncation.html
+++ b/templates/mac-truncation.html
@@ -16,13 +16,13 @@
                 <span> at </span><a href="/">cyfraeviolae.org</a>
             </div>
             <div class="crumbs">
-                <a href="/git/forbidden-salamanders">source code</a>
-                <span class="sep"> · </span>
                 <a href="/forbidden-salamanders/key-commitment">key commitment</a>
                 <span class="sep"> · </span>
                 <a href="/forbidden-salamanders/nonce-reuse">nonce reuse</a>
                 <span class="sep"> · </span>
 				<a href="/forbidden-salamanders/mac-truncation"><strong>mac truncation</strong></a>
+                <span class="sep"> · </span>
+                <a href="/git/forbidden-salamanders">source code</a>
             </div>
         </div>
         <p>
diff --git a/templates/nonce-reuse.html b/templates/nonce-reuse.html
index 249d00e..9049f4e 100644
--- a/templates/nonce-reuse.html
+++ b/templates/nonce-reuse.html
@@ -16,13 +16,13 @@
                 <span> at </span><a href="/">cyfraeviolae.org</a>
             </div>
             <div class="crumbs">
-                <a href="/git/forbidden-salamanders">source code</a>
-                <span class="sep"> · </span>
                 <a href="/forbidden-salamanders/key-commitment">key commitment</a>
                 <span class="sep"> · </span>
                 <a href="/forbidden-salamanders/nonce-reuse"><strong>nonce reuse</strong></a>
                 <span class="sep"> · </span>
                 <a href="/forbidden-salamanders/mac-truncation">mac truncation</a>
+                <span class="sep"> · </span>
+                <a href="/git/forbidden-salamanders">source code</a>
             </div>
         </div>
         <p>