Section capitalization and other formatting issues

easy.typ

@@ -62,4 +62,5 @@
 #chapter("src/fhe-takeaways.typ")
 
 #part[Oblivious RAM]
-#chapter("src/oram.typ")
+#chapter("src/oram.typ")
+#chapter("src/oram-takeaways.typ")

src/2pc-takeaways.typ

@@ -1,6 +1,6 @@
 #import "preamble.typ":*
 
-#takeaway[2PC Takeaways][
+#takeaway[2PC takeaways][
 1. A _garbled circuit_ allows Alice and Bob to jointly compute some
   function over their respective secret inputs. We can think of this
   as your prototypical _2PC_ (two-party computation).

src/copy-constraints.typ

@@ -3,7 +3,7 @@
 #let rbox(s) = [#text(red)[#ellipse(stroke: red, inset: 2pt, s)]]
 #let bbox(s) = [#text(blue)[#rect(stroke: blue, inset: 4pt, s)]]
 
-= Copy Constraints in PLONK <copy-constraints>
+= Copy constraints in PLONK <copy-constraints>
 
 Now we elaborate on Step 3 which we deferred back in @copy-constraint-deferred.
 As an example, the constraints might be:

src/ec.typ

@@ -249,7 +249,7 @@ for all our cryptographic primitives*
   while the prime $p$ is unnamed and doesn't get any screen-time later.
 ]
 
-= Discrete Logarithm <discretelog>
+= Discrete logarithm <discretelog>
 
 For our systems to be useful, rather than relying on factoring,
 we will rely on the so-called _discrete logarithm_ assumption.

src/fhe-takeaways.typ

@@ -1,6 +1,6 @@
 #import "preamble.typ":*
 
-#takeaway[FHE Takeaways][
+#takeaway[FHE takeaways][
 1. A _fully homomorphic encryption_ protocol allows Bob to compute some function $f(x)$ for Alice in a way that Bob doesn't get to know $x$ or $f(x)$.
 2. The hard problem backing known FHE protocols is the _learning with errors (LWE)_ problem, which comes down to deciding if a system of "approximate equations" over $FF_q$ is consistent.
 3. The main idea of this approach to FHEs is to use "approximate eigenvalues" as the encrypted computation and an "approximate eigenvector" as the secret key.

src/fhe0.typ

@@ -1,6 +1,6 @@
 #import "preamble.typ":*
 
-= FHE and Levelled FHE
+= FHE and levelled FHE
 <fhe-intro>
 
 Alice has a secret $x$, and Bob has a function $f$.

src/fhe2.typ

@@ -1,6 +1,6 @@
 #import "preamble.typ":*
 
-= Public-Key Cryptography from LWE
+= Public-key cryptography from LWE
 <lwe-crypto>
 
 In @lwe-small

src/intro.typ

@@ -69,7 +69,7 @@ and $x_i$ is the $i$-th person's income.
 Two-party computation makes a promise that we'll be able to do this
 for _any_ function $F$ as long as we can implement it in code. It generalizes to _multi-party computation (MPC)_, which is one of the main classes of programmable cryptography.
 
-== SNARK: proofs of general statements
+== SNARK: Proofs of general statements
 
 A powerful way of thinking about a signature scheme is that it is a *proof*. Specifically, Alice's signature is a proof that "I [the
 person who generated the signature] know Alice's private key." Similarly, a
@@ -130,7 +130,7 @@ Only one of the scrambled requests is the request you are interested in;
 the others keep the server from learning
 which request you care about.
 
-= Programmable Cryptography in the World
+= Programmable cryptography in the world
 
 In the past decade, there has been a surprisingly high amount of theoretical work but also
 a surprisingly low amount of implementation work on primitives in programmable cryptography.

src/kzg-takeaways.typ

@@ -1,6 +1,6 @@
 #import "preamble.typ":*
 
-#takeaway[KZG Takeaways][
+#takeaway[KZG takeaways][
 1. _Elliptic curves_ are very useful in cryptography. Roughly speaking, they are sets of points (usually in $FF_p^2$) that satisfy some group law / "addition." The BN254 curve is a good "typical curve" to keep in mind.
 2. The _discrete logarithm_ assumption is a common "hard problem assumption" used in cryptography with different groups. Specifically, since elliptic curves are groups, discrete logarithm over elliptic curves is very often used.
 3. _Commitment schemes_ are ways for one party to commit values to another. Elliptic curves enable _Pedersen commitments_, a very useful example of a commitment scheme.

src/mpc.typ

@@ -1,6 +1,6 @@
 #import "preamble.typ":*
 
-= Garbled Circuits
+= Garbled circuits
 
 Imagine Alice and Bob each have some secret values
 $a$ and $b$, and would like to jointly compute some function $f$ over
@@ -11,12 +11,12 @@ $f (a , b)$, but Alice shouldn’t learn anything about $b$ (other than
 what could be learned by knowing both $a$ and $f (a , b)$), and likewise
 for Bob.
 
-Yao’s Garbled Circuits is one of the most well-known 2PC protocols.
+Yao’s garbled circuits is one of the most well-known 2PC protocols.
 The protocol is quite clever, and optimized variants of the protocol are
 being
 #cite("https://github.com/privacy-scaling-explorations/mpz/tree/dev/crates/mpz-garble")[implemented and used today];.
 
-== The Problem
+== The problem
 <the-problem>
 Here is our problem setting, slightly more formally:
 
@@ -30,7 +30,7 @@ Here is our problem setting, slightly more formally:
 - Alice and Bob would like to jointly compute $f (a , b)$ without
   revealing their secrets to each other.
 
-== Outline of Solution
+== Outline of solution
 
 Our solution will contain two key components:
 - Alice constructs a _garbled circuit_

src/oram-takeaways.typ

@@ -0,0 +1,10 @@
+#import "preamble.typ":*
+
+#takeaway[ORAM takeaways][
+1. _Oblivious RAM_ is a system to hide memory access patterns from a server.
+2. The server stores encrypted data blocks in a binary tree,
+  and it does not learn which blocks correspond to which memory items.
+3. Every time the ORAM client accesses a block, it writes that block back to the root.
+4. A randomized eviction procedure moves blocks away from the root,
+  so individual nodes of the tree don't overflow.
+]

src/oram.typ

@@ -167,7 +167,7 @@ two blocks are accessed together). As mentioned earlier, one can
 such statistical information to infer sensitive
 secrets.
 
-== Important observation.
+== Important observation
 <important-observation.>
 The above naive solution 3 gives us the following useful insight:
 informally, if we want a "non-trivial" ORAM scheme, it appears that we
@@ -184,7 +184,7 @@ improvement called #cite("https://eprint.iacr.org/2013/280.pdf", "Path ORAM"),
 which is the scheme
 that Signal has deployed.
 
-== Server data structure.
+== Server data structure
 <server-data-structure.>
 The server stores a binary tree, where each node is called a
 #emph[bucket];, and each bucket is a finite array that can hold up to
@@ -194,7 +194,7 @@ later. Some of the blocks stored by the server are #emph[real];, other
 blocks are #emph[dummy];. As will be clear later, these dummy blocks are
 introduced for security.
 
-== Main path invariant.
+== Main path invariant
 <main-path-invariant.>
 The most important invariant is that at any point of time, each block is
 mapped to a random path in the tree (also referred to as the block’s
@@ -203,7 +203,7 @@ leaf node — and thus a path can be specified by the corresponding leaf
 node’s identifier. When a block is mapped to a path, it means that the
 block can legitimately reside anywhere along the path.
 
-== Imaginary position map.
+== Imaginary position map
 <imaginary-position-map.>
 For the time being, we will rely on the following cheat (an assumption
 that we can get rid of later). We assume that the client can store a
@@ -217,15 +217,15 @@ progressively smaller ORAMs.
 <operations>
 We now describe how to access blocks in our ORAM scheme.
 
-== Fetching a block.
+== Fetching a block
 <fetching-a-block.>
 Given how our data structures are set up, accessing a block is very
 easy: the client simply looks up its local position map, finds out on
 which path the block is residing, and then reads each and every block on
 the path. As long as the main invariant is respected, the client is
 guaranteed to find the desired block.
 
-== Remapping a block.
+== Remapping a block
 <remapping-a-block.>
 Recall that earlier, we have gained the informal insight that whenever a
 block is accessed, it should relocate. Here, whenever we access a block,
@@ -258,7 +258,7 @@ capacity of $Z$, and if we keep writing blocks back to the root, soon
 enough the root bucket will overflow! Therefore, we now introduce a new
 procedure called #emph[eviction] to cope with this problem.
 
-== Eviction.
+== Eviction
 <eviction.>
 Eviction is a maintenance operation performed upon every data access to
 ensure that none of the buckets in the ORAM tree will ever overflow
@@ -299,7 +299,7 @@ a few important considerations when performing such eviction:
     data block will be evicted to one of its children. To ensure
     security, a dummy eviction is performed for the child that does not
     receive a block; further, if the bucket chosen for eviction is
-    empty, dummy evictions are performed on both children buckets. In
+    empty, dummy evictions are performed on both child buckets. In
     this figure, $R$ denotes a real eviction and $D$ denotes a dummy
     eviction.
   ]
@@ -334,7 +334,7 @@ So far, we have not argued why any bucket that receives a block always
 has space for this block — we will give an informal analysis later to show
 that this is indeed the case.
 
-== Algorithm pseudo-code.
+== Algorithm pseudo-code
 <algorithm-pseudo-code.>
 We present the algorithm’s pseudo-code in Algorithms~@alg:access and
 @alg:evict.
@@ -401,7 +401,7 @@ We will now discuss why the aforementioned binary-tree ORAM construction
 
 2) is correct (except with negligible probability).
 
-== Obliviousness.
+== Obliviousness
 <obliviousness.>
 Obliviousness is easy to see. 
 
@@ -414,7 +414,7 @@ Second,
 the entire eviction process does not depend on the input requests
 at all.
 
-== Correctness.
+== Correctness
 <correctness.>
 Correctness is somewhat more tricky to argue. As mentioned earlier, to
 argue correctness, we must argue why no overflow will ever occur except

src/ot.typ

@@ -1,6 +1,6 @@
 #import "preamble.typ":*
 
-= Oblivious Transfer
+= Oblivious transfer
 <ot>
 
 Alice has $n$ messages $x_1, dots, x_n$.

src/snark-takeaways.typ

@@ -1,6 +1,6 @@
 #import "preamble.typ":*
 
-#takeaway[SNARK Takeaways][
+#takeaway[SNARK takeaways][
 1. A _SNARK_ can be used to succinctly prove that a piece of computation has been done correctly; specifically, it proves to some Verifier that the Prover had the K(nowledge) of some information that worked as feasible inputs to some computational circuit.
 2. The _arithmetization_ of the circuit is a way of converting circuits to arithmetic. Specifically for PLONK (but also other SNARKs, e.g. Groth16), our arithmetization is systems of quadratic equations over $FF_q$, meaning that what PLONK does under the hood is prove that a system of these equations are satisfied.
 3. The work under the hood of PLONK comes down to polynomial commitments (specifically KZG). KZG allows PLONK's gate checks and copy checks.