2008-09-22 26 views
4

J'ai ce code C à faire multiplications sur GF (8):Optimize y = x * x dans le champ Galois arithmétique

int32_t GaloisMultiply (int32_t a, int32_t b) 
{ 
    int32_t i; 
    int32_t mask = 0x100; 
    int32_t y = 0; 

    for(i=0;i<8;i++) 
    { 
     if(b & mask) 
     { 
      y ^= a; 
     } 
     mask >>= 1; 
     y <<= 1; 
    } 

    if(b & 0x1) 
    { 
     y ^= a; 
    } 

    return(y); 
} 

qui est plus ou moins la mise en œuvre du texte livre.

Je me demande s'il y a une optimisation intelligente pour l'algorithme ci-dessus si je peux affirmer que a est toujours b, par ex. Je fais la quadrature au lieu de la multiplication. Je ne suis pas après une utilisation cryptographique btw. Je veux juste utiliser le fait que x * x dans GF (8) entrelace les bits de x avec zéro bits un par un.

Il y a déjà des méthodes assez intelligentes pour faire l'entrelacement des bits, mais comme j'ai découvert que x * x dans GF (8) fait l'entrelacement des bits (par accident) je ne peux pas m'empêcher de l'utiliser pour les optimisations d'entrelacement de bits.

Des idées?

Répondre

4

Basé sur une table? link

Et lorsque vous êtes limité à x * x, c'est une matrice clairsemée.

Voici une autre good paper (and a library)

+0

Mais je suis désolé, je ne pense pas qu'ils utilisent l'effet d'équerrage (entrelacement de bits) dont vous parlez explicitement (ou si cela en compte vraiment améliore les performances). –

+0

La méthode basée sur la table devrait être beaucoup plus rapide, que vous soyez au carré ou non –

+0

L'approche basée sur les tables fait l'affaire. Merci. –

0

Vous pourriez probablement écrire un peu d'assemblage pour faire un meilleur travail. Cependant, je serais assez surpris si c'était le goulot d'étranglement dans votre application; avez-vous fait du profilage? Cette fonction ne semble pas devoir être optimisée.

+0

Il s'agit en effet d'un goulot d'étranglement. Si je cours le code sur une architecture différente qui fait la multiplication dans le matériel, j'accélère jusqu'à 30% d'accélération. –

0

Ceci est probablement pas ce que vous cherchez, mais voici un petit speedup:

Passe un seul argument, si elles sont garantis d'être le même.

0

Il pourrait aider le compilateur un peu pour marquer "a" et "b" comme const. Ou dérouler la boucle à la main. Ce serait triste si ça aidait, mais ...

N'est-ce pas un champ de mines patent, au fait?

1
int32_t GaloisMultiply(int32_t a) 
{ 
    int32_t y = 0; 
    int32_t b = a & 0x01ff; 

    while (b) 
    { 
    if (b & 1) 
     y ^= a; 

    a <<= 1; 
    b >>= 1; 
    } 
    return y; 
} 

Ou si vous aimez:

int32_t GaloisMultiply(int32_t a) 
{ 
    int32_t y = 0; 
    for (int32_t b = a & 0x01ff; b; b >>= 1) 
    { 
    if (b & 1) 
     y ^= a; 

    a <<= 1; 
    } 
    return y; 
} 

La raison pour laquelle cette approche est plus efficace que le code original ci-dessus est principalement parce que la boucle est effectuée uniquement jusqu'à ce que tous les bits « intéressants » dans l'argument sont consommés plutôt que de vérifier aveuglément tous les (9) bits.

Une approche basée sur une table sera cependant plus rapide.

+0

Vous devriez ajouter quelques détails pour expliquer pourquoi ce serait plus rapide –

+0

merci, après avoir un look qui semble être aussi court que possible. Je vais utiliser des tables bien. C'est plus rapide. –

1

La table de consultation est certainement la plus rapide pour le quadrillage galois à base polynomiale. C'est aussi le plus rapide pour la multiplication en utilisant GF (8), mais les tables deviennent trop grandes pour les champs plus grands utilisés dans ECC. Pour la multiplication dans des champs plus grands, le meilleur algorithme est la méthode "de gauche à droite" ... (voir http://www.amazon.com/Elliptic-Cryptography-Springer-Professional-Computing/dp/038795273X algorithme 2.36, page 50).

+0

Si vous utilisez l'arithmétique polynomiale pour la cryptographie, il peut être judicieux d'utiliser des tables de recherche. Au moins si vous utilisez un ordinateur à usage général. Les adresses de mémoire que vous recherchez dépendront des valeurs que vous calculez, et donc des ensembles de cache impliqués. Il y a beaucoup, beaucoup, de documents dans lesquels les attaquants observent les échecs de cache à plusieurs reprises, et parviennent ainsi à briser le crypto. Il y a même eu quelques casse du monde réel de cette manière. En général, sauf si vous êtes dans un système embarqué, évitez les tables de recherche. –