From: guyeux Date: Sat, 10 Dec 2011 11:19:42 +0000 (+0100) Subject: Relecture du prng cryptosur X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/prng_gpu.git/commitdiff_plain/568ccd6776e38446e0338d420f423c1d53aa4475?ds=sidebyside;hp=4635b3f66f097ccf0ad342948e2a29906bdbb32a Relecture du prng cryptosur --- diff --git a/prng_gpu.tex b/prng_gpu.tex index 6782175..ff2d42a 100644 --- a/prng_gpu.tex +++ b/prng_gpu.tex @@ -996,9 +996,9 @@ tab1, tab2: Arrays containing combinations of size combination\_size\;} o2 = threadIdx-offset+tab2[offset]\; \For{i=1 to n} { t=xor-like()\; - t=t $\hat{ }$ shmem[o1] $\hat{ }$ shmem[o2]\; + t=t $\wedge$ shmem[o1] $\wedge$ shmem[o2]\; shared\_mem[threadId]=t\; - x = x $\hat{ }$ t\; + x = x $\wedge$ t\; store the new PRNG in NewNb[NumThreads*threadId+i]\; } @@ -1230,56 +1230,55 @@ algorithm (Algorithm~\ref{algo:gpu_kernel2}). Due to Proposition~\ref{cryptopr it simply consists in replacing the {\it xor-like} PRNG by a cryptographically secure one. We have chosen the Blum Blum Shum generator~\cite{BBS} (usually denoted by BBS) having the form: -$$x_{n+1}=x_n^2~ mod~ M$$ where $M$ is the product of two prime numbers. These -prime numbers need to be congruent to 3 modulus 4. BBS is +$$x_{n+1}=x_n^2~ mod~ M$$ where $M$ is the product of two prime numbers (these +prime numbers need to be congruent to 3 modulus 4). BBS is known to be very slow and only usable for cryptographic applications. 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 less than $2^{32}$ and the number $M$ need to be -less than $2^{16}$. So in practice we can choose prime numbers around +$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 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 -$log_2(log_2(x_n))$). So to generate a 32 bits number, we need to use -8 times the BBS algorithm with different combinations of $M$. This -approach is not sufficient to pass all the tests of TestU01 because -the fact of having chosen small values of $M$ for the BBS leads to -have a small period. So, in order to add randomness we proceed with +$log_2(log_2(M))$). In other words, to generate a 32 bits number, we need to use +8 times the BBS algorithm with possibly different combinations of $M$. This +approach is not sufficient to be able to pass all the TestU01, +as small values of $M$ for the BBS lead to + small periods. So, in order to add randomness we proceed with the followings modifications. \begin{itemize} \item -First we define 16 arrangement arrays instead of 2 (as described in -algorithm \ref{algo:gpu_kernel2}) but only 2 are used at each call of -the PRNG kernels. In practice, the selection of which combinations -arrays will be used is different for all the threads and is determined +Firstly, we define 16 arrangement arrays instead of 2 (as described in +Algorithm \ref{algo:gpu_kernel2}), but only 2 of them are used at each call of +the PRNG kernels. In practice, the selection of combinations +arrays to be used is different for all the threads. It is determined by using the three last bits of two internal variables used by BBS. -This approach adds more randomness. In algorithm~\ref{algo:bbs_gpu}, -character \& performs the AND bitwise. So using \&7 with a number -gives the last 3 bits, so it provides a number between 0 and 7. +%This approach adds more randomness. +In Algorithm~\ref{algo:bbs_gpu}, +character \& is for the bitwise AND. Thus using \&7 with a number +gives the last 3 bits, providing so a number between 0 and 7. \item -Second, after the generation of the 8 BBS numbers for each thread we -have a 32 bits number for which the period is possibly quite small. So -to add randomness, we generate 4 more BBS numbers which allows us to -shift the 32 bits numbers and add upto 6 new bits. This part is -described in algorithm~\ref{algo:bbs_gpu}. In practice, if we call -{\it strategy}, the number representing the strategy, the last 2 bits -of the first new BBS number are used to make a left shift of at least +Secondly, after the generation of the 8 BBS numbers for each thread, we +have a 32 bits number whose period is possibly quite small. So +to add randomness, we generate 4 more BBS numbers to +shift the 32 bits numbers, and add up to 6 new bits. This improvement is +described in Algorithm~\ref{algo:bbs_gpu}. In practice, the last 2 bits +of the first new BBS number are used to make a left shift of at most 3 bits. The last 3 bits of the second new BBS number are add to the strategy whatever the value of the first left shift. The third and the fourth new BBS numbers are used similarly to apply a new left shift and add 3 new bits. \item -Finally, as we use 8 BBS numbers for each thread, the store of these +Finally, as we use 8 BBS numbers for each thread, the storage of these numbers at the end of the kernel is performed using a rotation. So, internal variable for BBS number 1 is stored in place 2, internal -variable for BBS number 2 is store ind place 3, ... and internal +variable for BBS number 2 is stored in place 3, ..., and finally, internal variable for BBS number 8 is stored in place 1. \end{itemize} - \begin{algorithm} \KwIn{InternalVarBBSArray: array with internal variables of the 8 BBS @@ -1305,9 +1304,9 @@ tab: 2D Arrays containing 16 combinations (in first dimension) of size combinat t|=BBS1(bbs1)\&7\; t<<=BBS7(bbs7)\&3\; t|=BBS2(bbs2)\&7\; - t=t $\hat{ }$ shmem[o1] $\hat{ }$ shmem[o2]\; + t=t $\wedge$ shmem[o1] $\wedge$ shmem[o2]\; shared\_mem[threadId]=t\; - x = x $\hat{ }$ t\; + x = x $\wedge$ t\; store the new PRNG in NewNb[NumThreads*threadId+i]\; } @@ -1318,11 +1317,31 @@ tab: 2D Arrays containing 16 combinations (in first dimension) of size combinat \label{algo:bbs_gpu} \end{algorithm} -In algorithm~\ref{algo:bbs_gpu}, t<<=4 performs a left shift of 4 bits -on the variable t and stores the result in t. BBS1(bbs1)\&15 selects -the last four bits of the result of BBS1. It should be noticed that -for the two new shifts, we use arbitrarily 4 BBSs that have previously -been used. +In Algorithm~\ref{algo:bbs_gpu}, $n$ is for the quantity +of random numbers that a thread has to generate. +The operation t<<=4 performs a left shift of 4 bits +on the variable $t$ and stores the result in $t$, and +$BBS1(bbs1)\&15$ selects +the last four bits of the result of $BBS1$. +Thus an operation of the form $t<<=4; t|=BBS1(bbs1)\&15\;$ +realizes in $t$ a left shift of 4 bits, and then puts +the 4 last bits of $BBS1(bbs1)$ in the four last +positions of $t$. +Let us remark that to initialize $t$ is not a necessity as we +fill it 4 bits by 4 bits, until having obtained 32 bits. +The two last new shifts are realized in order to enlarge +the small periods of the BBS used here, to introduce a variability. +In these operations, we make twice a left shift of $t$ of \emph{at most} +3 bits and we put \emph{exactly} the 3 last bits from a BBS into +the 3 last bits of $t$, leading possibly to a loss of a few +bits of $t$. + +It should be noticed that this generator has another time the form $x^{n+1} = x^n \oplus S^n$, +where $S^n$ is referred in this algorithm as $t$: each iteration of this +PRNG ends with $x = x \wedge t;$. This $S^n$ is only constituted +by secure bits produced by the BBS generator, and thus, due to +Proposition~\ref{cryptopreuve}, the resulted PRNG is cryptographically +secure