From d53fd5c63c58ea00b8249b3ce2dc95315ea624e1 Mon Sep 17 00:00:00 2001 From: cyfraeviolae Date: Wed, 31 Aug 2022 00:03:26 -0400 Subject: updates --- templates/key-commitment.html | 27 ++++++++++++++++----------- templates/mac-truncation.html | 2 +- templates/nonce-reuse.html | 8 +++++--- 3 files changed, 22 insertions(+), 15 deletions(-) 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 Fast Message Franking: From Invisible Salamanders to Encryptment.

+

+ 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. +

Colliding MACs

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 

             %PDF-1.7
             %µ¶
- 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 [DATA]. + The header is followed by a sequence of objects. A simple object + with id 1 0 containing a stream is shown below, with + the data for the stream inserted at [DATA]. 
             1 0 obj
             <<>>
@@ -218,15 +223,15 @@ go build -o /tmp/decrypt-aes-gcm /tmp/decrypt-aes-gcm.go
             [DATA]
             endstream
             endobj
- At the end of the file, an xref table determines how the objects are layed out in space, - and finally, the file ends with the line %%EOF, after which no more bytes are read by the PDF parser. + At the end of the file, an xref table summarizes the byte offsets of each object in the file. + The file ends with the line %%EOF.

- 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 - xref table does not reference this new object, the - first PDF will not attempt to render the additional data. -

+ 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. +

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 0 0 @@ -399,10 +404,10 @@ go build -o /tmp/decrypt-aes-gcm /tmp/decrypt-aes-gcm.go

- Show me the code. + Example with code. 
-from aesgcmanalysis import att_merge_jpg_bmp
+from aesgcmanalysis import att_merge_jpg_bmp, att_merge_pdf_pdf
 
 with open('first.jpg', 'rb') as h:
     jpg = h.read()
diff --git a/templates/mac-truncation.html b/templates/mac-truncation.html
index 24d4889..742a0c8 100644
--- a/templates/mac-truncation.html
+++ b/templates/mac-truncation.html
@@ -352,7 +352,7 @@
- Show me the code. + Example with code. 
 from aesgcmanalysis import xor, gmac, gcm_encrypt, mac_truncation_recover_secrets
diff --git a/templates/nonce-reuse.html b/templates/nonce-reuse.html
index eff36b4..5412050 100644
--- a/templates/nonce-reuse.html
+++ b/templates/nonce-reuse.html
@@ -165,8 +165,9 @@
         

             We plug \(h\) back into the first equation to recover \(s\), and we
             can forge the MAC for arbitary ciphertext under the same nonce.
-            Note that there may be multiple possible monomial roots; in this
-            case, one can check each possibility against the enemy.
+            Note that there may be multiple possible roots; in this
+            case, one can check each possibility against the enemy, or perform
+            the attack twice on two pairs of intercepted messages.
         

             

                 One can use SageMath to compute factors of a polynomial:
@@ -189,6 +190,7 @@ for factor, _ in p.factor():
 		
    
 			
  • The gcd of two polynomials is unique only up to multiplication by a non-zero constant because “greater” is defined for polynomials in terms of degree. When used in algorithms, gcd refers to the monic gcd, which is unique.
    • 
 			
  • The inverse Frobenius automorphism (i.e., square root) in \(\mathbb{F}_{2^{128}}\) is given by \(\sqrt{x} = x^{2^{127}}\).
    • 
+            
  • The authentication key must appear in one of the linear factors (those of the form \(y+h\)). This allows one to skip parts of the distinct-degree factorization and equal-degree factorization, making the algorithm much faster. Exercise: prove this claim.
    • 
 		

         

             Readers who wish to implement this attack themselves can try
@@ -198,7 +200,7 @@ for factor, _ in p.factor():
- Show me the code. + Example with code. 
 from aesgcmanalysis import xor, gmac, gcm_encrypt, gcm_decrypt, nonce_reuse_recover_secrets
-- 
cgit v1.2.3