]> AND Private Git Repository - prng_gpu.git/blob - reponse.tex
Logo AND Algorithmique Numérique Distribuée

Private GIT Repository
Fin de la retouche de la réponse
[prng_gpu.git] / reponse.tex
1 \documentclass{article}
2 \usepackage{color}
3
4 \begin{document}
5 \section{Editor}
6
7 \bigskip
8 \textit{As the reviewers point out, the paper is well written, is interesting, but there are some major concerns about both the practical aspects of the paper, as well as more theoretical aspects.  While the paper has only been reviewed by two reviewers, their concerns are enough to recommend that the author consider them carefully and then resubmit this paper as a new paper.}
9
10 \bigskip
11 \textit{Most of the issues raised are related to cryptography, and not to the acceleration work on a GPU.  The issue may be that during their preparation of this paper the authors were too focused on the acceleration work, and did not spend enough time being precise about the cryptography discussion.  The two reviewers are experts on cryptography, as well as acceleration techniques, and the review indicate that the analysis needs to be strengthened.}
12
13
14
15 \section{Reviewer: 1}
16
17
18 \bigskip
19 \textit{The authors should include a summary of  test measurements showing their method passes the test sets mentioned (NIST, Diehard, TestU01) instead of the one sentence saying it passed that is in section 1.}
20
21 \begin{color}{red} In section 1, we have added a small summary of test measurements performed with BigCrush of TestU01.
22 As other tests (NIST, Diehard, SmallCrush and Crush of TestU01 ) are deemed less selective, in this paper we did not use them.
23 \end{color}
24
25
26 \bigskip
27 \textit{Section 9:
28 The authors say they replace the xor-like PRNG with a cryptographically secure one, BBS, but then proceed to use extremely small values, as far as a cryptographer is concerned (modulus of $2^{16}$), in the computation  due  to the need to use 32 bit integers in the GPU and combine bits from multiple BBS generated values, but they never prove (or even discuss) how this  can be considered cryptographically secure due to the small  individual values. At the end of 9.1, the authors say $S^n$ is secure because it is formed from bits from the BBS generator, but do not consider if the use of such small values will lead to exhaust searches to determine individual bits. The authors either need to remove all of section 9 and or prove the resulting PRNG is cryptographically secure.}
29
30 A new section (namely, the Section 8.2) and a discussion at the end of Section 9.1 have been added to measure practically the security of the generator.
31
32 \bigskip
33 \textit{In the conclusion:
34 Reword last sentence of 1st paragraph
35 In the 2nd paragraph, change "these researches" to "this research" in  "we plan to extend ..."}
36
37 Done.
38
39
40 \section{Reviewer: 2}
41
42
43 \bigskip
44 \textit{The paper is, overall, well written and clear, with appropriate references to the relevant concepts and prior work. The motivation of the work, however, is not quite clear: the authors present (provable) chaotic properties of a PRNG as a security improvement, but provide no convincing argument beyond opinion (or hope).}
45
46
47 \bigskip
48 \textit{There seems to have been no effort in showing how the new PRNG improves on a single (say) xorshift generator, considering the slowdown of calling 3 of them per iteration (cf. Listing 1). This could be done, if not with the mathematical rigor of chaos theory, then with simpler bit diffusion metrics, often used in cryptography to evaluate building blocks of ciphers.}
49
50 A large section (Section 5) has been added, using and extending some previous works. It explains with more detail why topological chaos 
51 is useful to pass statistical tests. This new section contains both qualitative explanations and quantitative (experimental) evaluations.
52  Using several examples, this section illustrates  that defective PRNGs are always improved, according
53 to the NIST, DieHARD, and TestU01 batteries.
54
55 \bigskip
56 \textit{The generator of Listing 1, despite being proved chaotic, has several problems. First, it doesn't seem to be new; using xor to mix the states of several independent generators is standard procedure (e.g., [1]).}
57
58 The novelty of the approach is not in the discovery of a new kind of operator, but on the way to combine existing PRNGs. We propose
59 to realize a post-treatment based on chaotic iterations on these generators, in order to add topological properties that improve
60 their statistics while preserving their cryptographical security. In this document, generators that use XOR or BBS are only 
61 illustrative examples using the vectorial negation as iterative function in the chaotic iterations. Theorems 1 and 2 explain how to
62 replace this negation function, that leads to well known forms of generators, by more exotic ones. However, the choice of the vectorial
63 negation for illustrations has been motivated for speed.
64
65 Indeed, to the best of our knowledge, all the generators proposed in the literature mix only a few operations on previously obtained states:
66 arithmetic operations, exponentiation, shift, exclusive or. It is impossible to define a fast PRNG or to prove its security when
67 using more complicated operations, and the number of such operations that are mixed is necessary very low. Thus almost all
68  up-to-date fast or secure generators are very simple, like the BBS or all the XORshift-like ones. In a certain extend, they are all similar, 
69 due to the very reduced number of efficient elementary operations offered to define them.
70
71
72 \bigskip
73 \textit{Secondly, the periods of the 3 xorshift generators are not coprime --- this reduces the useful period of combining the sequences.}
74
75 We agree with the reviewer in the fact that using coprimes here will improve
76 the period of the resulted PRNG. Nevertheless the goal of this section was to
77 pass the Big Crush battery, and we achieve that with proposed combination of
78 the three XORshifts. 
79
80 \bigskip
81 \textit{Thirdly, by combining 3 linear generators with xor, another linear operation, you still get a linear generator, potentially vulnerable to stringent high-dimensional spectral tests.}
82
83 This first generator has not been designed for security reasons, but for speed: the
84 idea was to provide a very efficient version of our former generator that can pass
85 TestU01, and linear 
86 operations are a necessity when speed with pseudorandomness are desired. If the desire is to use a fast and statistically perfect PRNG, then simulations
87 proposed in this document show that this first PRNG is suitable. However, we have neither
88 claimed nor proved that this generator is secure. Indeed, we have only shown that some
89 chaotic iteration based post-treatment, like the one that use the vectorial negation,
90 can preserve the cryptographically secure property (while adding chaos), if this property has been established
91 for the inputted generator. As the inputted generator is not
92 cryptographically secure in the example disputed by the reviewer, we cannot apply this 
93 result. Indeed the first part of the document does not deal with security,
94 but it investigates the speed, chaos, and statistical quality of PRNGs.
95 A sentence has been added to clarify this point at the end of Section 5.4. 
96
97
98 \bigskip
99 \textit{The BBS-based generator of section 9 is anything but cryptographically secure. A 16-bit modulus (trivially factorable) gives out a period of at most $2^{16}$, which is neither useful nor secure. Its speed is irrelevant, as this generator as no practical applications whatsoever (a larger modulus, at least 1024-bit long, might be useful in some situations, but it will be a terrible GPU performer, of course).}
100
101
102 This claim is surprising, as this result is mathematically proven in the article: 
103 either there is something wrong in the proof, or the generator is cryptographically
104 secure. Indeed, there is probably a misunderstanding of this notion, which does
105 not deal with the practical aspects of security. For instance, BBS is 
106 cryptographically secure, but whatever the size of the keys, a brute force attack always
107 achieve to break it. It is only a question of time: with sufficiently large primes,
108 the time required to break it is astronomically large, making this attack completely
109 impracticable: being cryptographically secure is not a
110 question of key size.
111
112 \begin{color}{green}
113 Most of theoretical cryptographic definitions are somehow an extension of the
114 notion of one-way function. Intuitively a one way function is a function
115  easy to compute but  which is practically impossible to
116 inverse (i.e. from $f(x)$ it is not possible to compute $x$). 
117 Since the size of $x$ is known, it is always possible to use a brute force
118 attack, that is computing $f(y)$ for all $y$'s of the good size until
119 $f(y)\neq f(x)$. Informally, if a function is one-way, it means that every
120 algorithm that can compute $x$ from $f(x)$ with a good probability requires
121 a similar amount of time than the brute force attack. It is important to
122 note that if the size of $x$ is small, then the brute force attack works in
123 practice. The theoretical security properties don't guaranty that the system
124 cannot be broken, it guaranty  that if the keys are large enough, then the
125 system still works (computing $f(x)$ can be done, even if $x$ is large), and
126 cannot be broken in a reasonable time. The theoretical definition of a
127 secure PRNG is more technical than the one on one-way function but the
128 ideas are the same: a cryptographically secured PRNG can be broken 
129  by a brute force prediction, but not in a reasonable time if the
130  keys/seeds are large enough.
131 \end{color}
132
133 Nevertheless, new arguments have been added in several places of the revision of our paper, 
134 concerning more concrete and practical aspects of security, like the 
135 $(T,\varepsilon)-$security notion of Section 8.2. Such a practical evaluation
136 has not yet been performed for the GPU version of our PRNG, and the reviewer
137 has true when thinking that these aspects are fundamentals to determine whether
138 the proposed PRNG can face or not attacks in practice. A formula similar to what
139 has been computed for the BBS (as in Section 8.2) must be found in future work,
140 to measure how much time an attacker must have to break the proposed generator
141 when considering the parameters we have chosen (this computation is a difficult
142 task). 
143 Sentenses have been added in several places (like at the end of Section 9.1)
144 summarizing this.
145
146 \bigskip
147 \textit{To sum it up, while the theoretical part of the paper is interesting, the practical results leave much to be desired, and do not back the thesis that chaos improves some quality metric of the generators.} 
148
149
150 We hope now that, with the new sections added to the document (like the Section 5), we have convinced the reviewers that to add chaotic properties in 
151 existing generators can be of interest.
152
153 \bigskip
154 \textit{On the theoretical side, you may be interested in Vladimir Anashin's work on ergodic theory on p-adic (specifically, 2-adic) numbers to prove uniform distribution and maximal period of generators. The $d_s(S, \check{S})$ distance loosely resembles the p-adic norm.}
155
156 Thank you for this information. However, we have already established the uniform distribution in \cite{bcgr11:ip} (recalled in Theorem 2).
157
158 \bigskip
159 \textit{Typos and other nitpicks:\\
160  - Blub Blum Shub is misspelled in a few places as "Blum Blum Shum";}
161  
162 These misspells have been corrected (sorry for that).
163  
164 \bigskip
165 \textit{ - Page 12, right column, line 54: In "$t<<=4$", the $<<$ operation is using the `` character instead.}
166
167 \bigskip
168 \textit{ [1] Howes, L., and Thomas, D. "Efficient random number generation and application using CUDA." In GPU Gems 3, H. Nguyen, Ed. NVIDIA, 2007, Ch. 37. }
169
170
171 \bibliographystyle{plain} 
172 \bibliography{mabase}
173
174 \end{document}