Le but principal de notre d´emarche est d’´evaluer l’apport relatif du parall´elisme aussi bien pour le gain en vitesse qu’il peut amener que pour la s´ecurit´e apparente que semble fournir la superposition temporelle de deux calculs ind´ependants.
Nous pouvons citer une impl´ementation mat´erielle bas´ee sur du halving qu’est [65]. Dans ce papier, les auteurs proposent d’utiliser le parall´elisme naturellement pr´esent au sein des formules d’addition de points et de division par deux de points. Leur architecture est pipelin´ee de mani`ere `a rendre ces op´erations tr`es rapides : l’op´eration la plus couteuse en temps n’occupera que 8 cycles d’horloge. Ces solutions occupent une grande surface silicium et ont ´et´e con¸cues pour la performance pure. Nous ne nous comparerons pas `a cette impl´ementation car ce que nous souhaitons vraiment mesurer est l’apport relatif du parall´elisme et non la performance brute. D’une mani`ere g´en´erale, le calcul d’un halving (trouver P tel que 2 × P = Q) est bien plus rapide que celui d’un doubling (pour P , ´
etablir la valeur de 2×P ). Nous utilisons, en effet, ici, un syst`eme de coordonn´ees affines : un doubling requiert une inversion au niveau du corps fini et trois multiplications. Il faut sp´ecifiquement dix multiplications pour calculer A−1 dans GF(2233). Le halving, quant `
a lui, ne n´ecessite que deux multiplications (en coordonn´ees affines, toujours), le calcul de la solution quadratique λ2+ λ = c (qui est r´ealis´e en dm/we cycles, tr`es peu face aux m cycles de la multiplication ou aux 10 × m -environ- cycles de l’inversion), le calcul d’une racine carr´ee (un d´ecalage circulaire) et une poign´ee d’additions (tr`es rapides dans GF(2m)). ´Etant donn´ee la disparit´e des op´erations de doubling et de halving, couper la clef en deux parties ´egales ne sera ´evidemment pas l’optimal en terme de rapidit´e d’ex´ecution. Nous devons maintenant trouver o`u couper la clef (dans l’hypoth`ese ou la clef n’a pas ´et´e recod´ee et qu’il y a donc, en moyenne, autant de 0 que de 1 dans l’´ecriture binaire de k). Si nous n´egligeons toutes les op´erations au niveau du corps
`
a l’exceptions faites des multiplications et des inversions, nous avons donc les coˆuts suivants :
halving 2 × M doubling I + 3 × M
add I + 3 × M
o`u M est le coˆut d’une multiplication et I celui d’une inversion. Pour un recodage binaire de la clef (ce qui sera notre cas ici), il y a, en moyenne, autant de 0 que de 1. Si l repr´esente le nombre de bits de la clef dont nous nous servons pour calculer un halve-and-add (et donc m − l bits pour la portion double-halve-and-add ), nous obtiendrons les coˆuts temporels (en nombre de cycles d’horloges) suivants :
H(l) = l
2× add + l × halving,
pour la partie halve-and-add et
D(l) = m − l
2 × add + (m − l) × doubling,
pour la partie double-and-add . Si les deux calculs sont lanc´es en parall`ele, le coˆut global de l’op´eration sera
C(l) = max(H(l), D(l)) + E
o`u E est un coˆut, l`a encore n´egligeable, de l’op´eration qui consiste `a additionner les deux points respectivement obtenus par les deux algorithmes de multiplications scalaires. La pr´esence de max provient du fait que le temps d’ex´ecution est plafonn´e par l’algorithme le plus lent. Nous obtenons les courbes de C(l) repr´esent´ees dans la figure4.7.
Nous observons, dans la figure4.7, un optimum autour de 0.7 × m, pour une clef dont le poids de Hamming est de m/2. D’apr`es les mesures r´eelles que nous avons obtenues sur ModelSim, nous approchons un optimal voisin de cette valeur th´eorique (voir figure4.8). Nous reportons dans le tableau4.1les valeurs (slices, LUTs, flip-flops (bascules)) tir´ees du logiciel ISE apr`es synth`ese, placement et routage. Nous avons aussi incorpor´e dans ces chiffres une version mono-core de notre processeur (impl´ementation mat´erielle d’un seul des deux cœurs) afin de montrer l’apport de la version parall`ele de notre multiplication
0 1e+006 2e+006 3e+006 4e+006 5e+006 6e+006 7e+006 8e+006 0 100 200 300 400 500 600
Nombre de Cycles (approximatif) pour [k]P
Key Split l m=163 m=233 m=283 m=409 m=571
Figure 4.7: Nombres de cycles (approximatifs et th´eoriques) n´ecessaires pour le calcul d’un [k]P selon l’endroit o`u la clef est coup´ee.
m Slices LUTs FFs Frq (MHz) PTS (×10−9) Dual-Core 163 1763 5365 4892 270 2345 233 2216 7035 5972 264 4731 283 2662 8339 6593 259 7061 409 3464 10794 8637 263 11309 571 5052 15669 11210 218 27420 Single-Core 163 791 2659 2467 278 1311 233 1154 3253 3004 264 3178 283 1366 3897 3335 250 3754 409 1453 5069 4335 271 5140 571 2571 8340 5627 229 12789
Table 4.1: Surface et fr´equence de notre crypto-processeur.
scalaire [k]P . Dans la version Dual-Core, nous prenons le param`etre l optimal (≈ 0.7m) pour r´ealiser la multiplication scalaire. Dans la version Mono-Core, nous lan¸cons une multiplication scalaire `a l’aide de l’algorithme halve-and-add (plus efficace que le double-and-add standard) sur l’enti`eret´e de la clef k. Le terme PTS est le sigle pour produit temps surface , c’est `a dire le produit entre le temps requis pour le calcul d’un [k]P et la surface (ici en slices) occup´ee par notre crypto-processeur. Plus le PTS est petit, plus la solution est avantageuse. Nous voyons que la version Dual-Core a un produit temps-surface moins int´eressant que la version Mono-core (nous obtenons mˆeme une version parall`ele plus lente qu’une version strictement s´equentielle pour GF(2571)). Cela est lar-gement explicable par l’hyper-comp´etitivit´e du halve-and-add face au double-and-add .
0 500000 1e+006 1.5e+006 2e+006 2.5e+006 3e+006 3.5e+006 4e+006 0 100 200 300 400 500 600 Nombre de Cycles [k]P Split Key 163 bits 233 bits 283 bits 409 bits 571 bits
Figure 4.8: Nombres de cycles mesur´es pour le calcul d’un [k]P selon l’endroit o`u la clef est coup´ee.
m Nombre de Cycles pour un [k]P PTS
163 318987 2082
233 474733 3984
283 593433 6099
409 887709 11692
571 1349080 31264
Table 4.2: Performance de l’algorithme parallel halve-and-add.
Malgr´e un apport pas forc´ement int´eressant du calcul parall`ele (le PTS est bien sup´erieur au PTS d’une version mono-cœur), celui-ci apporte en plus de sa vitesse une forme de protection contre les attaques SPAs, comme cela a ´et´e suppos´e dans [63]. ´Evidemment, l’architecture que nous avons propos´ee permet de lancer deux multiplications scalaires en mˆeme temps. D´ependant du contexte et des besoins, notre processeur peut se pro-grammer diff´eremment.
Nous avons aussi cod´e, `a l’aide de notre assembleur, l’algorithme du parallel halve-and-add dont nous faisions r´ef´erence dans la section4.5. Les r´esultats sont rassembl´es dans le tableau4.2. Nous y apercevons que cette approche est plus attrayante que l’ap-proche parall`ele pr´ec´edente pour les corps GF(2163), GF(2233), GF(2283) de par un PTS plus bas que celui d’un double-and-add et halve-and-add parall`ele.