Skip to content

Commit aa1e7c2

Browse files
authored
Merge pull request filecoin-project#220 from Kubuxu/snapdeal/security-sec
Add security section to FIP-0019
2 parents 0b56397 + 0a8fa26 commit aa1e7c2

File tree

1 file changed

+57
-3
lines changed

1 file changed

+57
-3
lines changed

FIPS/fip-0019.md

Lines changed: 57 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -201,16 +201,70 @@ TODO
201201

202202
### Loosing epsilon-Replication guarantees
203203

204-
This changes changes the security property of Filecoin. Retrievability of the files and space-hardness are still guaranteed. TODO: expand on this.
204+
**Assumption 1**: We work under the assumption that for each bit grinded on the `{\rhoi}i=1,...,N` an adversary can flip one bit of her choice on the original `R`.
205+
206+
We consider `\lambda = 80` as the security parameter. This means that we give the adversary a bit flip budget of 80 bits on `R` (by crafting `R*` such that these bits are flipped, keeping all the rest untouched) in order to make R* more compressible than `R`.
207+
208+
Observation: As we will see in what follows, in the case of our actual encoding (where a single `\rhoi` is shared among _K_ distinct nodes Dj), we'll be either more conservative than we should, according to Kolmogorov bounds.
209+
210+
In order to stay on the safe side, we have two independent security analysis, following two different paths that give us similar results.
211+
212+
The first analysis is a probabilistic one, and we refer to it as the "security against the flipping adversary". The second one is using an information theoretical argument based on Kolmogorov complexity.
213+
214+
215+
#### Analysis 1: Security against "2 bytes for 1 bit" Adversary
216+
217+
**Preliminaries:**
218+
Given a predetermined string of L bits, we take for granted that a random string has probability 2<sup>-L</sup> to contain it.
219+
We will consider bit strings of K_consecutive `0`s (or `1`s). Note that it is the same when considering patterns like `01` or `10`, the only difference is that those sequences would allow for less compression.
220+
**Assumption 2**: An adversary can compress ~2 consecutive bytes (we would consider 2 bytes per node, but it can happen anywhere) by flipping a single bit.
221+
This means having substrings s that are of the form `s = 0000000100000000` (or its negation).
222+
Note that the probability of `s` (or negation of `s`) to happen is 2<sup>-15</sup>.
223+
Since the adversary can adaptively choose the bits to flip, we are just assuming he finds 80 of these strings in a 32GiB string. 2 bytes out of 32 represent the 6.25% of a single node
224+
225+
Note 1: Remember that each randomness `\rhoi` is shared among K nodes, have 2<sup>30</sup>/K different hashes.
226+
As a consequence, we consider each compression performed on a node D to propagate on all the K nodes that share the same randomness with D.
227+
228+
**Assumption 3**: An adversary A is able to find a string of the form of `s = 000000010000000` (or equivalent) in 80 different nodes, each of those uses a different `\rhoi`
229+
230+
Note 2: Assumption 3 maximizes the propagation of the compression made by the adversary since all the local compression propagates to K nodes each. This results in a total compression of 80*0.0625*K nodes out of 2<sup>30</sup>
231+
232+
With H = 2<sup>9</sup> and K = 2<sup>21</sup> we obtain a total compression under 1%.
233+
234+
Assume we have 2<sup>9</sup> different hashes. This means that we have a total compression, according to Assumption 2 and Assumption 3 of ~1%.
235+
236+
#### Analysis 2: Based on Kolmogorov Complexity (Information Theoretic Argument)
237+
**Information Theoretic Argument**: Given a string `S` of size N with incompressibility V, for any adversary that modifies `S` into `S'` by flipping T bits of his choice, we have that the incompressibility of `S'` is at least _V - T*(log(N) + log(log(N))+1)_.
238+
**Proof**: Assume by contradiction that there exists a string `S''` which is more compressible than `S'`.
239+
Then it means that it is possible to compress `S` into a string `S*` of length _| S'' | + T*(log(N) + 2*log(log(N))+1) < V_ .
240+
241+
Note: _T*(log(N) + 2*log(log(N))+1)_ are the bits needed in order to be able to store the T bit positions where the adversary flipped the bits, using self delimiting codes (References: this [paper](https://eprint.iacr.org/2021/162.pdf), page 9; this [book](https://core.ac.uk/download/pdf/301633813.pdf), Section 2.2).
242+
243+
Given the following:
244+
We assume `R` to be incompressible, and we then set the incompressibility of `R` to `N`.
245+
We assume an adversary can flip 80 bits of his choice in `R`.
246+
To be conservative, given that we are considering 2<sup>30</sup>/K different hashes, we apply the compressibility lower bound on a vector of size N' = 2<sup>30</sup>/K nodes
247+
248+
According to the lower bound, we get that an adversary that can flip 80 bits of his choice on `R` can not compress `R` to a string that has compressibility smaller than _N' - 80(log(N') + 2*log(log(N')) + 1)_.
249+
250+
In order to be even more conservative, we are using `N` instead of `N'` in the compressibility reduction factor. We are then considering that R can not be compressed to a string which is less compressible than 2<sup>30</sup>/K - 80(log(2<sup>30</sup>) + log(log(2<sup>30</sup>)) + 1) = 2<sup>30</sup>/ K - 80(30+11) .
251+
252+
As a consequence, we have that an adversary can compress a total of 80(30+11)*K bits out of 2<sup>30</sup>.
253+
254+
This means that, for K = 2<sup>21</sup> and 2<sup>9</sup> = 512 different hashes, we have that the additional spacegap is < 2.51%. Given in our case the distribution of the last bit of each node is not uniform, we also considered the case of nodes of 255 bits rather than 256. Spacegap in this case is < 2.5123%.
255+
If we allow for 1024 hashes, additional spacegap is bounded by < 1.26%. If as above we consider nodes of bit length 255 instead of 256 we still obtain that an additional spacegap bounded by < 1.26%
256+
205257

206258
### Poseidon-128
207259

208260
Poseidon-128 is zk-SNARK friendly hash function which is already widely used in Filecoin protocol.
209261
Both uses of Poseidon-128 include Domain Separation Tags such that the usage here does not clash with possible future use cases.
210262

211263
Domain Separation Tags used:
212-
- Encoding Randomness Generation: `XXXX`
213-
- Challenge Generation: `XXXX`
264+
- Encoding Randomness Generation: `2^40`
265+
- Challenge Generation: `2^40`
266+
267+
Domain Separate Tags for both are the same as their inputs are different.
214268

215269
## Incentive Considerations
216270

0 commit comments

Comments
 (0)