Handed-in Thesis

4_comparison.typ

@@ -211,15 +211,15 @@ Note that this does not contain the @ocsp staple or handshake signature included
 In comparison, a comparable Bikeshed certificate with a 256-bit ECDSA key would contain 704 authentication-related bytes, assuming 280 million active @ap:pl.
 The full certificate would be 785 bytes in size.
 Thus, the X.509 certificate chain has an overhead of 1,238 bytes, or 99~%, while the Bikeshed certificate has an overhead of 81 bytes, or 12~%.
-Even though we only analyzed a single example that closely, this indicates that the X.509/@asn1 format produces a significant overhead, that can be reduced by introducing a new certificate format.
+Even though we only analyzed a single example, it indicates that the X.509/@asn1 format produces a significant overhead, that can be reduced by introducing a new certificate format.
 An analysis of the certificate chains of the top websites implies that certificates are often even bigger than our example.
 #cite(<dennis_cert_size>, form: "author") investigated the size of certificate chains sent by roughly 75,000 of the Tranco top sites ranking~@tranco.
 It reveals that the 5#super[th] percentile of certificate chains is 2,308~bytes big, and the median certificate chain has 4,032~bytes.
 Applying existing certificate compression algorithms, this reduces to 1,619~bytes and 3,243~bytes, respectively~@dennis_cert_size.
 Consequently, even though X.509 certificates require fewer authentication-related bytes if they completely rely on the size-efficient @ecdsa algorithm, the inclusion of additional attributes and inefficient encoding result in @mtc:pl being smaller in practice, not only for @pq algorithms but also for classical algorithms.
 
 == Update Mechanism Considerations <sec:update_size>
-As with many optimizations, one does not get the results from @sec:certificate_size without a trade.
+As with many optimizations, one does not get the results from @sec:certificate_size without a trade-off.
 The @mtc architecture requires the @rp to regularly update the tree heads it trusts, as shown in Step 5 of @fig:mtc_overview.
 To pull the updates, the @rp regularly requires a connection to the Transparency Service.
 
@@ -343,7 +343,7 @@ This demonstrates that even the worst-case scenario with a full update of 150~@c
 //       - Times the number of CAs: $150 dot 18,608 = 2,791,200 => 2.7 "MB"$
 //     - Daily update without the signatures:
 == Common File Structure <sec:file_structure>
-Besides small update sizes, it is desirable to store #gls("mtc")-related data in a common place on an @os.
+Besides small update sizes, it is desirable to store #gls("mtc")-related data in a common directory within an @os.
 Having a common place for certificates on a single machine has multiple advantages.
 Firstly, it reduces the number of updates required in the @mtc architecture.
 Instead of every application pulling its updates, the @os can take care of it for various applications that depend on up-to-date tree heads.

6_conclusion.typ

@@ -30,7 +30,7 @@ Other scenarios require a bigger update bandwidth, but we expect them to be rele
 
 In addition to the size analysis, we estimated the computational cost associated with X.509 and @mtc.
 We pointed out that there is no difference for a server.
-Still, clients can save about 81~% to 93~% in computational cost per handshake when using classical signature algorithms and about 73~% to 85~% when using #gls("pq")-save signature algorithms.
+Still, clients can save about 81~% to 93~% in computational cost per handshake when using classical signature algorithms and about 73~% to 85~% when using #gls("pq")-safe signature algorithms.
 This is mainly because clients have to perform way fewer signature verifications, which are computationally expensive.
 Instead, clients have to perform hash operations to rebuild the Merkle Tree.
 Because hash operations are much more lightweight than signature verifications, the client saves computational resources, which in turn helps with a longer battery life or frees up resources for other tasks.

main.typ

@@ -12,7 +12,7 @@
 // ...
 
 #let title = "Master Thesis"
-#let subtitle = "Implementation and Analysis of Merkle Tree Certificates for Post-Quantum Secure authentication in TLS"
+#let subtitle = "Implementation and Analysis of Merkle Tree Certificates for Post-Quantum Secure Authentication in TLS"
 #let author = "Maximilian Pohl"
 #let student_number = "s1103073"