feat: Toss in summer notes

summer-notes-evan/.gitignore

@@ -0,0 +1 @@
+0xparc-summer-2024-notes.pdf

summer-notes-evan/0xparc-summer-2024-notes.typ

@@ -0,0 +1,14 @@
+#import "@local/evan:1.0.0":*
+
+#show: evan.with(
+  title: [Evan's notes],
+  subtitle: [0xPARC Summer 2024],
+  author: "Evan Chen",
+  date: datetime.today(),
+)
+
+#toc
+
+#include "src/symposium.typ"
+#include "src/research-workshop.typ"
+#include "src/math-seminar.typ"

summer-notes-evan/src/math-seminar.typ

@@ -0,0 +1,154 @@
+#import "@local/evan:1.0.0":*
+
+= Math seminar for August 12: Binius (Aard Vark)
+
+== Synopsis
+
+One of the annoyances about our cryptographic ecosystem right now is they
+often have different underlying base fields.
+For example, one system might use a 128-bit prime while the other uses a 256-bit prime.
+And then you have to figure out how to interact between them,
+and there may not be a great way to do this in general.
+
+So why don't we just use a two-element field $FF_2$?
+
+Well, the problem is that most of our protocols rely on $q$ over $FF_q$,
+say $q approx 2^256$.
+This is an important criteria because, for example, a random challenge comes from a huge space,
+so two polynomials that differ are unlikely to have many common roots.
+Over $FF_2$, we don't have this, $2$-element fields are too small.
+
+So in this math talk we're going to try to build a _finite extension_ of $FF_2$ that's big.
+
+== Review of complex numbers
+
+Recall that the way we extend $RR$ to $CC$ by adjoining a single element,
+traditionally named $i$, which is imagined as a root of the (irreducible) polynomial $X^2+1$.
+Our tower looks like
+
+$
+  i in& CC
+  & RR
+$
+
+After we do this, we can do addition, e.g.
+$ (a + b i)(c + d i) = (a c - b d) + (b c + a d) i. $
+Division can be done too since
+$ a + b i = a/(a^2+b^2) + b/(a^2+b^2) i. $
+
+== Construction of $FF_4$, the field with four elements
+
+We'd like to do the same thing by taking an irreducible quadratic polynomial over $FF_2$.
+There are four possible quadratic polynomials ($X^2$, $X^2+1$, $X^2+X$, $X^2+X+1$),
+and of these only the fourth one is irreducible.
+So let us agree to take $p_0$ to be a root of $X^2+X+1$.
+Then $FF_4$ will consist of our four elements
+$ FF_4 = { a p_0 + b | a in {0,1}, b in {0,1} }. $
+
+Our tower of fields now has two links in it:
+$
+  p_0 in& FF_4 \
+  & FF_2
+$
+
+As some practice with arithmetic in this fields:
+$
+  p_0^2 &= p_0 + 1 \
+  p_0 + p_0 &= (1+1) p_0 = 0 \
+  1/p_0 &= p_0 + 1 \
+  1/(p_0+1) &= p_0.
+$
+(Right now, this third identity might be easiest to find by guessing all four,
+since there are only four elements. The fourth one follows from the third identity.)
+
+Now for $FF_4$ we're going to imagine we encode our four elements using binary strings:
+$
+  0 &-> 00 \
+  1 &-> 10 \
+  p_0 &-> 01 \
+  p_0+1 &-> 11.
+$
+In other words, we encode $a+b p_0$ by simply writing $a b$.
+Then
+
+- Addition corresponds to just bitwise XOR; but
+- Multiplication is more annoying: $(a + b p_0)(c + d p_0) = (a c + b d) + (a d + b c + b d) p_0$.
+  We could imagine implementing this in a circuit.
+
+== Moving on to $FF_16$, the field with eight elements
+
+To extend $FF_4$ to $FF_16$,
+we need to guess a quadratic polynomial with coefficients in $FF_4$ which is irreducible.
+It turns out that about half of the choices will factor and half won't.
+
+But we standardize one particular choice to make things easier.
+Recall that $p_0 in F_4$.
+Ur next element $p_1$ will be chosen so that
+$ p_1 + 1/p_1 = p_0. $
+Indeed, we can check $ X + 1/X $ has no roots of $FF_4$ by trying them all.
+(Note that $p_0 + 1/p_0 = 1$ and $(p_0+1) + 1/(p_0+1) = 1$.)
+In still other words, $p_1$ is chosen to be one root of the quadratic
+$ X^2 - p_0 X + 1 = 0. $
+
+We then write
+$ FF_16 = { a p_1 + b | a in FF_4, b in FF_4 } $
+which indeed has $4^2 = 16$ elements.
+
+Our tower of fields now reads
+$
+  p_1 in& FF_16 \
+  p_0 in& FF_4 \
+  & FF_2
+$
+
+Multiplication can be done, e.g.
+$ p_1^2 = p_0 p_1 + 1. $
+As a more complicated example, we can calculate
+$
+  &#hide[=] (p_0 p_1 + 1)^2 \
+  &= p_0^2 p_1^2 + 1 \
+  &= p_0^2 (p_0 p_1 + 1) + 1 \
+  &= p_0^3 p_1 + (p_0^2 + 1) \
+  &= p_0 + p_1.
+$
+
+Division can be done by a system of equations or a "multiply-by-conjugate" trick,
+but we won't cover that here.
+
+== Keep going
+
+Now $16$ elements is still not good enough for cryptographic security,
+so we now have to show how we keep going.
+
+We go one level higher from $FF_16$ to $FF_256$ by introducing $p_2$ such that
+$ p_2 + 1 / p_2 = p_1 <=> p_2^2 + 1 = p_1 p_2. $
+
+(We won't prove that $t + 1/t != p_1$ for any $t in FF_16$,
+i.e. that $X^2 - p_1 X + 1$ does not factor in $FF_16$.
+I think a high-powered proof is to use the fact that the
+Chebyshev polynomials are irreducible modulo $2$.)
+
+Our tower now looks like:
+
+$
+  p_2 in& FF_256 \
+  p_1 in& FF_16 \
+  p_0 in& FF_4 \
+  & FF_2.
+$
+
+The pattern continues
+
+$ FF_256 = { a p_2 + b | a in FF_16, b in FF_16 } $
+
+
+Multiplication can be done in an analogous way, by induction:
+$ (a p_2 + b)(c p_2 + d)
+  &= a c p_2^2 + (b c + a d) p_2 + b d \
+  &= (b c + a d + a c) p_2 + (b d + a c) $
+
+Bit representations can done by induction as well.
+An $FF_16$ element could be written as
+$ a_0 + a_1 p _0 + a_2 p_1 + a_3 p_0 p_1 $
+and hence a four-bit string.
+An $FF_256$ element could be written with $8$ bits as you need.

summer-notes-evan/src/research-workshop.typ

@@ -0,0 +1,136 @@
+#import "@local/evan:1.0.0":*
+
+= Research workshop on August 3: Problem statements
+
+== Coding Theory I (Liam Eagen)
+
+#problem[
+  Solve conjecture 1 in
+  #url("https://cic.iacr.org/p/1/1/2/pdf")
+]
+
+== Dan Boneh's two problems
+
+1. Outsource SNARK proof generation to untrusted servers
+2. Efficient short _weighted_ threshold signature.
+
+Good progress in #url("https://eprint.iacr.org/2023/1609.pdf").
+
+=== Outsource SNARK proof generation to untrusted servers
+
+- We have a secret witness $w$, and a complicated circuit $C$,
+  and want a server to get a proof of $C(w) = 0$ (say).
+  But we don't want the server to learn $w$.
+- One method is a collaborative proof where we secret-share among $n$ servers.
+  [B-Ozdemir'21, GGJPS'23, CLMZ'23.]
+  As long as at most $n-1$ are malicious, we're OK.
+- Surprisingly, this uses zkSNARK with an MPC-friendly prover,
+  and the MPC adds almost no overhead.
+- But we need an assumption the servers are not colluding.
+
+#problem[
+  Can we do it with a single untrusted server?
+]
+
+The obvious approach is to use FHE:
+the powerful server could run the SNARK-prover inside an FHE.
+This is a theoretical approach, but is completely unpractical.
+
+#remark[
+  We don't need verifiable FHE for this, unlike some other situations:
+  because the output is an FHE proof, the client can just
+]
+
+The goal is to design a FHE-friendly SNARK:
+that is, the SNARK prover is a shallow circuit that can run inside FHE.
+
+#url("https://eprint.iacr.org/2023/1609")
+points out that FRI on hidden values is a viable approach.
+
+One other way to make the work shallower for the FHE is to do some rounds of interaction.
+
+=== Weighted signatures
+
+We have $n$ people with weights $w_1$, ..., $w_n$
+and we want a quorum $S subset.eq [n]$ to be able to sign iff
+$sum_(i in S) w_i > t$ for some threshold $t$.
+
+#remark[
+  Used in proof-of-stake sometimes.
+]
+
+The trivial way to do this is to use a non-weighted scheme
+and then give $w_i$ shares to the $i$th person; this is pretty inefficient.
+(But it's actually done in practice this way sometimes.)
+
+#problem[
+  We want a _practical_ scheme where all the following
+  are independent of $n$, $t$, and $(w_1, ..., w_n)$:
+
+  - the signature size,
+  - secret key size,
+  - public key size,
+  - verification time,
+  - and each party's signing team.
+]
+
+This is easy with generic SNARK techniques,
+because the aggregator could simply produce a proof
+it saw all the signatures from $S$.
+But we'd like a simple scheme that don't require SNARK's.
+
+== A new hash function (Jordi Baylina)
+
+Let $p := 2^64-2^32+1$ be the Goldilocks prime and work in $FF_p$.
+Our function has signature
+$ FF_p^8 arrow.r.hook FF_p^(12) -> FF_p^(12) arrow.r.twohead FF_p^4. $
+The first arrow is inclusion where the last four coordinates are dropped to zero.
+The last arrow is projection onto the first four coordinates.
+The main operation is the center arrow.
+
+We view the input as $vec(v) in FF_p^(12)$ and apply a certain function $30$ times.
+It involves a linear part, and a seventh powers.
+
+This is a new hash function and hasn't been thought about much yet.
+
+#problem[
+  Try to either find a preimage or a collision for this hash function.
+]
+
+#remark[
+  Colin's question clarifies that the $arrow.r.hook$ and $arrow.r.twohead$
+  are necessary because the main arrow is easily invertible
+  (they are invertible matrix multiplications and seventh powers in $FF_p$).
+]
+
+== PIR open problems (Elaine Shi)
+
+To start, repeat the following content in @pir:
+
+- Statement of PIR problem
+- Comparison to ORAM
+- The discussion of the two naive attempts
+
+The following two facts are known:
+
+1. In a single-server setting,
+  cryptography is necessary for sub-linear bandwidth/communication.
+2. Classical PIR with no pre-processing always requires at least $Omega(n)$ compute.
+
+In a 2-server, Dvir-Gopi'16 (FOCS best paper) gets $n^o(1)$ bandwidth
+and $n^O(sqrt(log log n slash log n))$ computation for the server.
+
+With $omega(1)$ servers, doubly-efficient schemes exist with
+$n^o(1)$ bandwidth and $n^(1+o(1))$ server space.
+
+Questions (purely information theoretic):
+
+#problem[
+  In DG'16, can we make the server compute linear without cryptographic assumptions?
+]
+(Boneh says this already known with crytographic assumptions.)
+
+#problem[
+  For 2-server IT, can we have a scheme with $o(n^(1/3))$ bandwidth
+  and sublinear computation?
+]