\usepackage{tabularx}
\usepackage{multirow}
+\usepackage{color}
+
% Pour mathds : les ensembles IR, IN, etc.
\usepackage{dsfont}
reported, when the parallelization of a good PRNG is realized.
This is why ad-hoc PRNGs for each possible architecture must be found to
achieve both speed and randomness.
-On the other side, speed is not the main requirement in cryptography: the great
-need is to define \emph{secure} generators able to withstand malicious
+On the other hand, speed is not the main requirement in cryptography: the most
+important aspect is to define \emph{secure} generators able to withstand malicious
attacks. Roughly speaking, an attacker should not be able in practice to make
the distinction between numbers obtained with the secure generator and a true random
sequence. Or, in an equivalent formulation, he or she should not be
Finally, a small part of the community working in this domain focuses on a
third requirement, that is to define chaotic generators.
-The main idea is to take benefits from a chaotic dynamical system to obtain a
-generator that is unpredictable, disordered, sensible to its seed, or in other word chaotic.
-Their desire is to map a given chaotic dynamics into a sequence that seems random
+The main idea is to take advantage from a chaotic dynamical system to obtain a
+generator that is unpredictable, disordered, sensible to its seed, or in other words chaotic.
+Their goal is to map a given chaotic dynamics into a sequence that seems random
and unassailable due to chaos.
-However, the chaotic maps used as a pattern are defined in the real line
+However, the chaotic maps used as patterns are defined in the real line
whereas computers deal with finite precision numbers.
This distortion leads to a deflation of both chaotic properties and speed.
Furthermore, authors of such chaotic generators often claim their PRNG
-as secure due to their chaos properties, but there is no obvious relation
+are secure due to their chaos properties, but there is no obvious relation
between chaos and security as it is understood in cryptography.
This is why the use of chaos for PRNG still remains marginal and disputable.
of a PRNG. But they are not substitutable for security or statistical perfection.
Indeed, to the authors' mind, such properties can be useful in the two following situations. On the
one hand, a post-treatment based on a chaotic dynamical system can be applied
-to a PRNG statistically deflective, in order to improve its statistical
+to a statistically deflective PRNG, in order to improve its statistical
properties. Such an improvement can be found, for instance, in~\cite{bgw09:ip,bcgr11:ip}.
On the other hand, chaos can be added to a fast, statistically perfect PRNG and/or a
cryptographically secure one, in case where chaos can be of interest,
stringent statistical evaluation of a sequence claimed as random.
This battery can be found in the well-known TestU01 package~\cite{LEcuyerS07}.
More precisely, each time we performed a test on a PRNG, we ran it
-twice in order to observe if all $p-$values are inside [0.01, 0.99]. In
+twice in order to observe if all $p-$values were inside [0.01, 0.99]. In
fact, we observed that few $p-$values (less than ten) are sometimes
outside this interval but inside [0.001, 0.999], so that is why a
second run allows us to confirm that the values outside are not for
proposed generator, without any lack of chaos or statistical properties.
In particular, a version of this PRNG on graphics processing units (GPU)
is proposed.
-Although GPU was initially designed to accelerate
+Although GPUs were initially designed to accelerate
the manipulation of images, they are nowadays commonly used in many scientific
applications. Therefore, it is important to be able to generate pseudorandom
-numbers inside a GPU when a scientific application runs in it. This remark
+numbers inside a GPU when it is run by a scientific application runs in it. This remark
motivates our proposal of a chaotic and statistically perfect PRNG for GPU.
Such device
allows us to generate almost 20 billion of pseudorandom numbers per second.
Furthermore, we show that the proposed post-treatment preserves the
-cryptographical security of the inputted PRNG, when this last has such a
+cryptographical security of the inputted PRNG, when the latter has such a
property.
Last, but not least, we propose a rewriting of the Blum-Goldwasser asymmetric
key encryption protocol by using the proposed method.
{\bf Main contributions.} In this paper a new PRNG using chaotic iteration
is defined. From a theoretical point of view, it is proven that it has fine
-topological chaotic properties and that it is cryptographically secured (when
-the initial PRNG is also cryptographically secured). From a practical point of
+topological chaotic properties and that it is cryptographically secure (when
+the initial PRNG is also cryptographically secure). From a practical point of
view, experiments point out a very good statistical behavior. An optimized
original implementation of this PRNG is also proposed and experimented.
Pseudorandom numbers are generated at a rate of 20GSamples/s, which is faster
than in~\cite{conf/fpga/ThomasHL09,Marsaglia2003} (and with a better
-statistical behavior). Experiments are also provided using BBS as the initial
+statistical behavior). Experiments are also provided using
+\begin{color}{red} the well-known Blum-Blum-Shub
+(BBS)
+\end{color}
+as the initial
random generator. The generation speed is significantly weaker.
%Note also that an original qualitative comparison between topological chaotic
%properties and statistical tests is also proposed.
Such generators are experimented in
Section~\ref{sec:experiments}.
We show in Section~\ref{sec:security analysis} that, if the inputted
-generator is cryptographically secure, then it is the case too for the
+generator is cryptographically secure, then it is also the case of the
generator provided by the post-treatment.
A practical
security evaluation is also outlined in Section~\ref{sec:Practicak evaluation}.
Numerous research works on defining GPU based PRNGs have already been proposed in the
literature, so that exhaustivity is impossible.
-This is why authors of this document only give reference to the most significant attempts
+This is why the authors of this document only only refer to the most significant attempts
in this domain, from their subjective point of view.
The quantity of pseudorandom numbers generated per second is mentioned here
only when the information is given in the related work.
1MSample/s whereas a billion numbers per second is 1GSample/s.
In \cite{Pang:2008:cec} a PRNG based on cellular automata is defined
-with no requirement to an high precision integer arithmetic or to any bitwise
+with no requirement to a high precision integer arithmetic or to any bitwise
operations. Authors can generate about
3.2MSamples/s on a GeForce 7800 GTX GPU, which is quite an old card now.
However, there is neither a mention of statistical tests nor any proof of
Authors of~\cite{conf/fpga/ThomasHL09} have studied the implementation of some
PRNGs on different computing architectures: CPU, field-programmable gate array
-(FPGA), massively parallel processors, and GPU. This study is of interest, because
+(FPGA), massively parallel processors, and GPU. This study is interesting, because
the performance of the same PRNGs on different architectures are compared.
FPGA appears as the fastest and the most
efficient architecture, providing the fastest number of generated pseudorandom numbers
per joule.
-However, we notice that authors can ``only'' generate between 11 and 16GSamples/s
+However, we notice that the authors can ``only'' generate between 11 and 16GSamples/s
with a GTX 280 GPU, which should be compared with
the results presented in this document.
We can remark too that the PRNGs proposed in~\cite{conf/fpga/ThomasHL09} are only
other things
Xorwow~\cite{Marsaglia2003} and some variants of Sobol. The tests reported show that
their fastest version provides 15GSamples/s on the new Fermi C2050 card.
-But their PRNGs cannot pass the whole TestU01 battery (only one test is failed).
+But their PRNGs cannot pass the whole TestU01 battery (only one test has failed).
\newline
\newline
-We can finally remark that, to the best of our knowledge, no GPU implementation has been proven to be chaotic, and the cryptographically secure property has surprisingly never been considered.
+We can finally remark that, to the best of our knowledge, no GPU implementation has ever been proven to be chaotic, and the cryptographically secure property has surprisingly never been considered.
\section{Basic Recalls}
\label{section:BASIC RECALLS}
\mathds{N}^*$ of elements (or \emph{cells}), so that each cell has a
Boolean \emph{state}. Having $\mathsf{N}$ Boolean values for these
cells leads to the definition of a particular \emph{state of the
-system}. A sequence which elements belong to $\llbracket 1;\mathsf{N}
+system}. A sequence whose elements belong to $\llbracket 1;\mathsf{N}
\rrbracket $ is called a \emph{strategy}. The set of all strategies is
denoted by $\llbracket 1, \mathsf{N} \rrbracket^\mathds{N}.$
For instance, when considering the TestU01 battery with its 588 tests, we obtained 261
failures for a PRNG based on the logistic map alone, and
this number of failures falls below 138 in the Old CI(Logistic,Logistic) generator.
-In the XORshift case (146 failures when considering it alone), the results are more amazing,
-as the chaotic iterations post-treatment makes it fails only 8 tests.
+In the XORshift case (146 failures when considering it alone), the results are more impressive,
+as the chaotic iterations post-treatment fails with only 8 tests of the TestU01 battery.
Further investigations have been systematically realized in \cite{bfg12a:ip}
using a large set of inputted defective PRNGs, the three most used batteries of
tests (DieHARD, NIST, and TestU01), and for all the versions of generators we have proposed.
as an integer having $\mathsf{N}$ bits too). More precisely, the $k-$th
component of this state (a binary digit) changes if and only if the $k-$th
digit in the binary decomposition of $S^n$ is 1.
+\begin{color}{red}
+Obviously, when $S$ is periodic of period $p$, then $x$ is periodic too of
+period either $p$ or $2p$, depending on the fact that, after $p$ iterations,
+the state of the system may or not be the same as before these iterations.
+\end{color}
The single basic component presented in Eq.~\ref{equation Oplus} is of
ordinary use as a good elementary brick in various PRNGs. It corresponds
\begin{proof}
$d_e$ is the Hamming distance. We will prove that $d_s$ is a distance
-too, thus $d$, as being the sum of two distances, will also be a distance.
+too, thus $d$, being the sum of two distances, will also be a distance.
\begin{itemize}
\item Obviously, $d_s(S,\check{S})\geqslant 0$, and if $S=\check{S}$, then
$d_s(S,\check{S})=0$. Conversely, if $d_s(S,\check{S})=0$, then
claimed in the lemma.
\end{proof}
-We can now prove the Theorem~\ref{t:chaos des general}.
+We can now prove Theorem~\ref{t:chaos des general}.
\begin{proof}[Theorem~\ref{t:chaos des general}]
Firstly, strong transitivity implies transitivity.
needs to have independent blocks of threads that can be computed
simultaneously. In general, the larger the number of threads is, the
more local memory is used, and the less branching instructions are
-used (if, while, ...), the better the performances on GPU is.
+used (if, while, ...), the better the performances on GPU are.
Obviously, having these requirements in mind, it is possible to build
a program similar to the one presented in Listing
\ref{algo:seqCIPRNG}, which computes pseudorandom numbers on GPU. To
\subsection{Naive Version for GPU}
-It is possible to deduce from the CPU version a quite similar version adapted to GPU.
+It is possible to deduce from the CPU version a fairly similar version adapted to GPU.
The simple principle consists in making each thread of the GPU computing the CPU version of our PRNG.
Of course, the three xor-like
PRNGs used in these computations must have different parameters.
In a given thread, these parameters are
randomly picked from another PRNGs.
The initialization stage is performed by the CPU.
-To do it, the ISAAC PRNG~\cite{Jenkins96} is used to set all the
+To do so, the ISAAC PRNG~\cite{Jenkins96} is used to set all the
parameters embedded into each thread.
The implementation of the three
PRNGs\footnote{we multiply this number by $2$ in order to count 32-bits numbers}
and the pseudorandom numbers generated by our PRNG, is equal to $100,000\times ((4+5+6)\times
2+(1+100))=1,310,000$ 32-bits numbers, that is, approximately $52$Mb.
+\begin{color}{red}
+Remark that the only requirement regarding the seed regarding the security of our PRNG is
+that it must be randomly picked. Indeed, the asymptotic security of BBS guarantees
+that, as the seed length increases, no polynomial time statistical test can
+distinguish the pseudorandom sequences from truly random sequences with non-negligible probability,
+see, \emph{e.g.},~\cite{Sidorenko:2005:CSB:2179218.2179250}.
+\end{color}
This generator is able to pass the whole BigCrush battery of tests, for all
the versions that have been tested depending on their number of threads
\subsection{Improved Version for GPU}
-As GPU cards using CUDA have shared memory between threads of the same block, it
+As GPU cards using CUDA have a shared memory between threads of the same block, it
is possible to use this feature in order to simplify the previous algorithm,
i.e., to use less than 3 xor-like PRNGs. The solution consists in computing only
one xor-like PRNG by thread, saving it into the shared memory, and then to use the results
array\_comb1, array\_comb2: Arrays containing combinations of size combination\_size\;}
\KwOut{NewNb: array containing random numbers in global memory}
-\If{threadId is concerned} {
- retrieve data from InternalVarXorLikeArray[threadId] in local variables including shared memory and x\;
+\If{threadIdx is concerned} {
+ retrieve data from InternalVarXorLikeArray[threadIdx] in local variables including shared memory and x\;
offset = threadIdx\%combination\_size\;
o1 = threadIdx-offset+array\_comb1[offset]\;
o2 = threadIdx-offset+array\_comb2[offset]\;
\For{i=1 to n} {
t=xor-like()\;
t=t\textasciicircum shmem[o1]\textasciicircum shmem[o2]\;
- shared\_mem[threadId]=t\;
+ shared\_mem[threadIdx]=t\;
x = x\textasciicircum t\;
- store the new PRNG in NewNb[NumThreads*threadId+i]\;
+ store the new PRNG in NewNb[NumThreads*threadIdx+i]\;
}
- store internal variables in InternalVarXorLikeArray[threadId]\;
+ store internal variables in InternalVarXorLikeArray[threadIdx]\;
}
\end{small}
\caption{Main kernel for the chaotic iterations based PRNG GPU efficient
we must guarantee that this dynamical system iterates on the space
$\mathcal{X} = \mathcal{P}\left(\llbracket 1, \mathsf{N} \rrbracket\right)^\mathds{N}\times\mathds{B}^\mathsf{N}$.
The left term $x$ obviously belongs to $\mathds{B}^ \mathsf{N}$.
-To prevent from any flaws of chaotic properties, we must check that the right
+To prevent any flaws of chaotic properties, we must check that the right
term (the last $t$), corresponding to the strategies, can possibly be equal to any
integer of $\llbracket 1, \mathsf{N} \rrbracket$.
3GSamples/s. With the optimized version, it is approximately equal to
20GSamples/s. Finally we can remark that both GPU cards are quite similar, but in
practice, the Tesla C1060 has more memory than the GTX 280, and this memory
-should be of better quality.
+is of better quality.
As a comparison, Listing~\ref{algo:seqCIPRNG} leads to the generation of about
138MSample/s when using one core of the Xeon E5530.
To a certain extend, it is also the case with the secure BBS-based version, the speed deflation being
explained by the fact that the former version has ``only''
chaotic properties and statistical perfection, whereas the latter is also cryptographically secure,
-as it is shown in the next sections.
+as shown in the next sections.
A direct numerical application shows that this attacker
-cannot achieve its $(10^{12},0.2)$ distinguishing
+cannot achieve his/her $(10^{12},0.2)$ distinguishing
attack in that context.
The modulus operation is the most time consuming operation for current
GPU cards. So in order to obtain quite reasonable performances, it is
required to use only modulus on 32-bits integer numbers. Consequently
-$x_n^2$ need to be lesser than $2^{32}$, and thus the number $M$ must be
-lesser than $2^{16}$. So in practice we can choose prime numbers around
+$x_n^2$ need to be inferior than $2^{32}$, and thus the number $M$ must be
+inferior than $2^{16}$. So in practice we can choose prime numbers around
256 that are congruent to 3 modulus 4. With 32-bits numbers, only the
4 least significant bits of $x_n$ can be chosen (the maximum number of
indistinguishable bits is lesser than or equals to
}
\KwOut{NewNb: array containing random numbers in global memory}
-\If{threadId is concerned} {
- retrieve data from InternalVarBBSArray[threadId] in local variables including shared memory and x\;
+\If{threadIdx is concerned} {
+ retrieve data from InternalVarBBSArray[threadIdx] in local variables including shared memory and x\;
we consider that bbs1 ... bbs8 represent the internal states of the 8 BBS numbers\;
offset = threadIdx\%combination\_size\;
o1 = threadIdx-offset+array\_comb[bbs1\&7][offset]\;
t$<<$=shift\;
t|=BBS2(bbs2)\&array\_shift[shift]\;
t=t\textasciicircum shmem[o1]\textasciicircum shmem[o2]\;
- shared\_mem[threadId]=t\;
+ shared\_mem[threadIdx]=t\;
x = x\textasciicircum t\;
- store the new PRNG in NewNb[NumThreads*threadId+i]\;
+ store the new PRNG in NewNb[NumThreads*threadIdx+i]\;
}
- store internal variables in InternalVarXorLikeArray[threadId] using a rotation\;
+ store internal variables in InternalVarXorLikeArray[threadIdx] using a rotation\;
}
\end{small}
\caption{main kernel for the BBS based PRNG GPU}
and statistically perfect generator on GPU, its
$(T,\varepsilon)-$security must be determined, and
a formulation similar to Eq.\eqref{mesureConcrete}
-must be established. Authors
+must be established. The authors
hope to achieve this difficult task in a future
work.
namely the BigCrush.
Furthermore, we have shown that when the inputted generator is cryptographically
secure, then it is the case too for the PRNG we propose, thus leading to
-the possibility to develop fast and secure PRNGs using the GPU architecture.
+the possibility of developping fast and secure PRNGs using the GPU architecture.
An improvement of the Blum-Goldwasser cryptosystem, making it
behave chaotically, has finally been proposed.
In future work we plan to extend this research, building a parallel PRNG for clusters or
grid computing. Topological properties of the various proposed generators will be investigated,
and the use of other categories of PRNGs as input will be studied too. The improvement
-of Blum-Goldwasser will be deepened. Finally, we
+of Blum-Goldwasser will be deepened.
+\begin{color}{red}
+Another aspect to consider might be different accelerator-based systems like
+Intel Xeon Phi cards and speed measurements using such cards: as heterogeneity of
+supercomputers tends to increase using other accelerators than GPGPUs,
+a Xeon Phi solution might be interesting to investigate.
+\end{color}
+ Finally, we
will try to enlarge the quantity of pseudorandom numbers generated per second either
in a simulation context or in a cryptographic one.
