Les indicateurs de strings-to-keys (S2K) sont utilisés pour convertir des phrases secrètes en clefs symétriques de cryptage et de décrytpage. Elles sont utilisés actuellement dans deux cas, pour crypter la partie secrète des clefs privés dans le trousseau de clefs privés, et pour convertir des phrases secrètes en clef de cryptage pour les messages cryptés symétriquement.
Il y a trois types d'identificateur de S2K actuellement compatible, comme décrit ci dessous :
Cette méthode effectue un hachage direct de la chaîne pour créer la clef de donnée. Voir ci dessous comment le hachage est effectué. Octet 0: 0x00 Octet 1: algorithme de hachage
La méthode Simple S2K hache la phrase secrète pour créer la clef de session. La manière dont cela est réalisé dépend de la taille de la clef de session (qui dépend (elle même) du chiffrage utilisé) et de la taille générée par l'algorithme de hachage. Si la taille du hachage est plus grand ou égale à celle de la clef de session, les octets de poids forts (ceux le plus à gauche) du hachage sont utilisés comme clef.
Si la taille de hachage est moins importante que celle de la clef, plusieurs instances du contexte de hachage sont créées -- assez pour produire la clef de donnée requise. Ces instances sont préchargés avec 0, 1, 2 ... octets de zéros (ce qui revient à dire que la première instance n'a pas de préchargement, la seconde est préchargée avec un octet de zéro, la troisième avec deux octets de zéros, et ainsi de suite).
Une fois qu'une donnée à été hachée, elle sont passée indépendamment dans chaque contexte de hachage. Comme les contextes on été initialisés différemment, ils vont produirent chacun un code haché différent. Une fois que la phrase secrète est hachée, les données issues des différents contextes de hachage sont concaténées, d'abord le hachage le plus à gauche, pour produire la clef de donnée, avec suppression des eventuels octets en trop sur la droite.
Cette méthode inclut une donnée "salée" dans l'identificateur S2K -- une donnée arbitraire -- qui est hachée avec la phrase secrète, pour empécher les attaques basés sur les mots de dictionnaires. Octet 0: 0x01 Octet 1: algorithme de hachage Octet 2-9: valeur salée sur 8 octet
Le S2K salé est exactement comme le S2K simple, à part que l'entrée des fonction(s) de hachage est constituée des 8 octets salés provenant de l'identificateur de S2K, suivie de la phrase secrète.
Cette méthode inclut à la fois une valeur salée et un octet de comptage. La valeur salée est combinée à la phrase secrète et la valeur résultante est hachée de manière répétitive. Cela augmente la quantité de travail nécessaire pour effectuer une attaque à base de mots de dictionnaires. Octet 0: 0x03 Octet 1: algorithme de hachage Octet 2-9: valeur salée sur octets Octet 10: compte, valeur codée sur un octet
Le compte est codé sur un nombre de un octet en utilisant la formule suivante :
#define EXPBIAS 6
compte = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);
|
La formule ci dessus est écrit en C, où << Int32 >> est un type pour un entier codé sur 32 bits, et la variable << c >> est le compte codé, l'octet 10.
Les S2K salés et itératifs hachent la phrase secrète et la valeur salée plusieurs fois. Le nombre total d'octets à être hachés est indiqué dans le compte codé du spécifieur S2K. Il faut bien voir que la valeur de comptage resultante est un compte d'octet du nombre d'octets à être hachés, et non un comptage itératif.
Au départ, un ou plusieurs contextes de hachages sont configurés comme dans les autres algorythmes S2K, suivant le nombre le nombre d'octets la clef de donnée a besoin. Puis la valeur salée, suivie par la phrase secrète sont hachés de manière répétitive jusqu'à ce que le nombre d'octets spécifiés par l'octet de compte aient été hachés. La seule exception est que si l'octet de compte est moins important que la taille de la valeur salée additionnée à la phrase secrète, ces deux derniers sont hachés même si la taille est plus grande que l'octet de compte.
Après le hachage effectué, la donnée est sortie du contexte(s) de hachage comme dans les autres algorithmes S2K.
Les implémentations DEVRAIENT ( SHOULD ) utiliser les spécifieurs de S2K salés ou salés et itératifs, car les spécifieurs S2K simple sont moins robustes aux attaques de type dictionnaires.
Un spécifieur S2K peut être enregistré dans le trousseau de clef secret pour spécifier la façon de convertir la phrase secrète en une clef qui debloque la donnée secrète. Les anciennes versions de PGP se contentaient de garder en mémoire un algorithme de codage d'octets précèdant la donnée secrète ou 0 pour indiquer que les donnée secrètes n'étaient pas encryptées. Le hachage MD5 était toujours utilisé pour convertir la phrase secrète en une clef pour l'algorithme de codage spécifique.
Pour une question de compatibilité, quand un spécifieur S2K est utilisé, la valeur spéciale 255 est enregistrée à la position où l'octet d'algorithme de hachage aurait été dans la vieille structure de données. Cela est immédiatemment suivi par un simple octet d'identification de l'algorithme, puis par le spécifieur S2K codé comme décrit ci dessus.
Cependant, avant les données secrètes on peut se trouver face à plusieurs possibilités : 0: les données secrètes ne sont pas cryptées
OpenPGP peut créer un paquet contenant une clef de cryptage de session symétrique (ESK) au début du paquet. Cela est utilisé pour autoriser les identifieurs S2K a etre utilisé pour la conversion de la phrase secrète ou pour créer des messages qui contiennent un mélange de clefs symétriques ESK et de clefs publiques ESK. Cela permet d'avoir des messages decryptable à la fois par une clef publique ou une phrase secrète.
PGP 2.x a toujours utilisé IDEA avec une conversion S2K lors de l'encryptage d'un message avec un algorithme symétrique. Cela n'est pas préférable, mais DOIT être utilisé pour garder la compatibilté avec les anciennes versions.
| Précédent | Sommaire | Suivant |
| Champs de temps | Niveau supérieur | Syntaxe des paquets |