Identificateur string-to-key (S2K)

Les indicateurs de string-to-key (S2K) sont utilisés pour convertir des phrases secrètes en clés symétriques de cryptage et de décryptage. Elles sont utilisées actuellement dans deux cas, pour crypter la partie secrète des clés privées dans le trousseau de clés privées, et pour convertir des phrases secrètes en clés de cryptage pour les messages cryptés symétriquement.

Type d'indentificateur string-to-key (S2K)

Il y a trois types d'identificateurs de S2K actuellement compatibles, comme décrit ci-dessous :

S2K Simple

Cette méthode effectue un hachage direct de la chaîne pour créer la clé 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 clé de session. La manière dont cela est réalisé dépend de la taille de la clé 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 grande ou égale à celle de la clé de session, les octets de poids forts (ceux le plus à gauche) du hachage sont utilisés comme clé.

Si la taille de hachage est moins importante que celle de la clé, plusieurs instances du contexte de hachage sont créées -- suffisamment pour produire la clé de donnée requise. Ces instances sont pré-chargées 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éros, la troisième avec deux octets de zéros, et ainsi de suite).

Une fois qu'une donnée a été hachée, elle est passée indépendamment dans chaque contexte de hachage. Comme les contextes ont é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 clé de donnée, avec suppression des éventuels octets en trop sur la droite.

S2K compliqué (salé)

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ées sur les mots du dictionnaire.
	    Octet 0:	0x01
	    Octet 1:	algorithme de hachage
	    Octet 2-9:	valeur salée sur 8 octets
	  

Le S2K salé est exactement comme le S2K simple, à part que l'entrée de(s) fonction(s) de hachage est constituée des 8 octets salés provenant de l'identificateur de S2K, suivie de la phrase secrète.

S2K itératif et salé

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 des mots du dictionnaire.
	    Octet 0:	0x03
	    Octet 1:	algorithme de hachage
	    Octet 2-9:	valeur salée sur 8 octets
	    Octet 10:	compte, valeur codée sur un octet
	  

Le compte est codé sur un octet en utilisant la formule suivante :

	  #define EXPBIAS 6
	  compte = ((Int32)16 + (c & 15)) <<  ((c  >> 4) + EXPBIAS);
	  

La formule ci-dessus est écrite 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 résultante est un compte d'octets 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 algorithmes S2K, suivant le nombre d'octets que la clé de donnée a besoin. Puis la valeur salée, suivie par la phrase secrète sont hachées de manière répétitive jusqu'à ce que le nombre d'octets, spécifié par l'octet de compte, ait été haché. 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, la donnée est sortie du(des) contexte(s) de hachage comme dans les autres algorithmes S2K.

Utilisation des 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 simples résistent moins bien aux attaques de type dictionnaire.

clé secrète de cryptage

Un spécifieur S2K peut être enregistré dans le trousseau de clés secrètes pour spécifier la façon de convertir la phrase secrète, en une clé qui débloque 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ées secrètes n'étaient pas en-cryptées. Le hachage MD5 était toujours utilisé pour convertir la phrase secrète en une clé 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 l'ancienne structure de données. Cela est immédiatement 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ées :
	    0:	les données secrètes ne sont pas cryptées
	  

clé symétrique de cryptage de message

OpenPGP peut créer un paquet contenant une clé de cryptage de session symétrique (ESK) au début du paquet. Cela est utilisé pour autoriser les identifieurs S2K à être utilisés pour la conversion de la phrase secrète ou pour créer des messages qui contiennent un mélange de clés symétriques ESK et de clés publiques ESK. Cela permet d'avoir des messages décryptables à la fois par une clé 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 compatibilité avec les anciennes versions.