Skip to content

Commit

Permalink
feat: Toss in summer notes
Browse files Browse the repository at this point in the history
  • Loading branch information
vEnhance committed Aug 12, 2024
1 parent b549dbf commit fcc861b
Show file tree
Hide file tree
Showing 6 changed files with 527 additions and 0 deletions.
1 change: 1 addition & 0 deletions summer-notes-evan/.gitignore
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
0xparc-summer-2024-notes.pdf
14 changes: 14 additions & 0 deletions summer-notes-evan/0xparc-summer-2024-notes.typ
Original file line number Diff line number Diff line change
@@ -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"
154 changes: 154 additions & 0 deletions summer-notes-evan/src/math-seminar.typ
Original file line number Diff line number Diff line change
@@ -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.
136 changes: 136 additions & 0 deletions summer-notes-evan/src/research-workshop.typ
Original file line number Diff line number Diff line change
@@ -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?
]
Loading

0 comments on commit fcc861b

Please sign in to comment.