4.1 Sel

Un sel dans la cryptographie basée sur mot de passe a traditionnellement servi l'objectif de produire un grand ensemble de clés correspondant à un mot de passe donné, dont l'une est sélectionnée au hasard selon le sel. Une clé individuelle dans l'ensemble est sélectionnée en appliquant une fonction de dérivation de clé KDF, comme

DK = KDF (P, S)

où DK est la clé dérivée, P est le mot de passe, et S est le sel. Cela présente deux avantages:

Il est difficile pour un adversaire de précalculer toutes les clés, ou même les clés les plus probables, correspondant à un dictionnaire de mots de passe. Si le sel fait 64 bits, par exemple, il y aura jusqu'à 2^64 clés pour chaque mot de passe. Un adversaire est donc limité à rechercher des mots de passe après qu'une opération basée sur mot de passe ait été effectuée et que le sel soit connu.
Il est peu probable que la même clé soit sélectionnée deux fois. Encore une fois, si le sel fait 64 bits, la probabilité de "collision" entre les clés ne devient significative qu'après environ 2^32 clés produites, selon le paradoxe des anniversaires. Le fait que les collisions soient peu probables répond à certaines préoccupations concernant les interactions entre plusieurs utilisations de la même clé qui peuvent survenir lors de l'utilisation de certaines techniques de chiffrement et d'authentification.

Dans le chiffrement basé sur mot de passe, la partie chiffrant un message peut s'assurer que ces avantages sont réalisés simplement en sélectionnant un sel large et suffisamment aléatoire lors de la dérivation d'une clé de chiffrement à partir d'un mot de passe. Une partie générant un code d'authentification de message peut obtenir une telle assurance de manière similaire.

La partie déchiffrant un message ou vérifiant un code d'authentification de message, cependant, ne peut pas être sûre qu'un sel fourni par une autre partie ait effectivement été généré au hasard. Il est possible, par exemple, que le sel ait été copié d'une autre opération basée sur mot de passe dans une tentative d'exploiter les interactions entre plusieurs utilisations de la même clé. Par exemple, supposons que deux parties légitimes échangent un message chiffré, où la clé de chiffrement est une clé de 80 bits dérivée d'un mot de passe partagé avec un certain sel. Un adversaire pourrait prendre le sel de ce chiffrement et le fournir à l'une des parties comme s'il était pour une clé de 40 bits. Si la partie révèle le résultat du déchiffrement avec la clé de 40 bits, l'adversaire pourrait être en mesure de résoudre pour la clé de 40 bits. Dans le cas où la clé de 40 bits est la première moitié de la clé de 80 bits, l'adversaire peut alors facilement résoudre pour les 40 bits restants de la clé de 80 bits.

Pour se défendre contre de telles attaques, soit l'interaction entre plusieurs utilisations de la même clé doit être soigneusement analysée, soit le sel doit contenir des données qui distinguent explicitement entre différentes opérations. Par exemple, le sel pourrait avoir un octet supplémentaire, non aléatoire, qui spécifie si la clé dérivée est pour le chiffrement, pour l'authentification de message, ou pour une autre opération.

Sur cette base, ce qui suit est recommandé pour la sélection du sel:

S'il n'y a pas de préoccupation concernant les interactions entre plusieurs utilisations de la même clé (ou un préfixe de cette clé) avec les techniques de chiffrement et d'authentification basées sur mot de passe prises en charge pour un mot de passe donné, alors le sel peut être généré au hasard et n'a pas besoin d'être vérifié pour un format particulier par la partie recevant le sel. Il devrait faire au moins huit octets (64 bits).
Sinon, le sel devrait contenir des données qui distinguent explicitement entre différentes opérations et différentes longueurs de clé, en plus d'une partie aléatoire qui fait au moins huit octets, et ces données devraient être vérifiées ou régénérées par la partie recevant le sel. Par exemple, le sel pourrait avoir un octet supplémentaire non aléatoire qui spécifie l'objectif de la clé dérivée. Alternativement, il pourrait être l'encodage d'une structure qui spécifie des informations détaillées sur la clé dérivée, telles que la technique de chiffrement ou d'authentification et un numéro de séquence parmi les différentes clés dérivées du mot de passe. Le format particulier des données supplémentaires est laissé à l'application.

Note: Si un générateur de nombres aléatoires ou un générateur pseudoaléatoire n'est pas disponible, une alternative déterministe pour générer le sel (ou la partie aléatoire de celui-ci) consiste à appliquer une fonction de dérivation de clé basée sur mot de passe au mot de passe et au message M à traiter. Par exemple, le sel pourrait être calculé avec une fonction de dérivation de clé comme S = KDF (P, M). Cette approche n'est pas recommandée si le message M est connu pour appartenir à un petit espace de messages (par exemple, "Oui" ou "Non"), cependant, car alors il n'y aura qu'un petit nombre de sels possibles.