From d53fd5c63c58ea00b8249b3ce2dc95315ea624e1 Mon Sep 17 00:00:00 2001
From: cyfraeviolae <cyfraeviolae>
Date: Wed, 31 Aug 2022 00:03:26 -0400
Subject: updates

---
 templates/key-commitment.html | 27 ++++++++++++++++-----------
 1 file changed, 16 insertions(+), 11 deletions(-)

(limited to 'templates/key-commitment.html')

diff --git a/templates/key-commitment.html b/templates/key-commitment.html
index da11bf7..f3a309e 100644
--- a/templates/key-commitment.html
+++ b/templates/key-commitment.html
@@ -150,6 +150,10 @@ go build -o /tmp/decrypt-aes-gcm /tmp/decrypt-aes-gcm.go
             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>
+		<p>
+			After reviewing the collisions below for JPEG/BMP files and PDF/PDF files, the reader is encouraged to try
+			to construct an attack for a different pair of file formats.
+		</p>
         <h4>Colliding MACs</h4>
         <p>
             First, we will describe a general strategy to create a ciphertext that yields the same MAC
@@ -209,8 +213,9 @@ go build -o /tmp/decrypt-aes-gcm /tmp/decrypt-aes-gcm.go
             <pre>
             %PDF-1.7
             %µ¶</pre>
-            The header is followed by a sequence of objects. A simple object containing a stream is shown below, with the data
-            for the object inserted at <code>[DATA]</code>.
+			The header is followed by a sequence of objects. A simple object
+			with id <code>1 0</code> containing a stream is shown below, with
+			the data for the stream inserted at <code>[DATA]</code>.
             <pre>
             1 0 obj
             &lt;&lt;&gt;&gt;
@@ -218,15 +223,15 @@ go build -o /tmp/decrypt-aes-gcm /tmp/decrypt-aes-gcm.go
             [DATA]
             endstream
             endobj</pre>
-            At the end of the file, an <code>xref</code> table determines how the objects are layed out in space,
-            and finally, the file ends with the line <code>%%EOF</code>, after which no more bytes are read by the PDF parser.
+            At the end of the file, an <code>xref</code> table summarizes the byte offsets of each object in the file.
+            The file ends with the line <code>%%EOF</code>.
         </p>
         <p>
-            Our strategy will be to place a new stream object at the beginning of the first PDF file. This object
-            will include the entirety of the second PDF file. Because the
-            <code>xref</code> table does not reference this new object, the
-            first PDF will not attempt to render the additional data.
-        </p>
+            Our strategy will be to place a new, unused stream object at the beginning of the first PDF file. This object
+            will include the entirety of the second PDF file. When decrypted under \(k_1\), the second PDF file
+			will not be rendered as it is included only in an unused object. When decrypted under \(k_2\), the initial
+			bytes of the first PDF and stream object opening will be commented out, so the second PDF file is rendered.
+		</p>
         <p>
             Fix an arbitrary nonce \(n\) and key \(k_1\). We need our ciphertext header \(c_H\) to decrypt to the following
             plaintext \(m_H\) under \(k_1\). We choose the object ID <code>0 0
@@ -399,10 +404,10 @@ go build -o /tmp/decrypt-aes-gcm /tmp/decrypt-aes-gcm.go
         </details>
 		<details>
 			<summary>
-                Show me the code.
+                Example with code.
 			</summary>
         <pre>
-from <a href="/git/forbidden-salamanders">aesgcmanalysis</a> import att_merge_jpg_bmp
+from <a href="/git/forbidden-salamanders">aesgcmanalysis</a> import att_merge_jpg_bmp, att_merge_pdf_pdf
 
 with open('first.jpg', 'rb') as h:
     jpg = h.read()
-- 
cgit v1.2.3