Fa paramètres permet de spécifier la méthode de hachage à utiliser, et fournit aussi différents paramètres à cette dernière, en particulier un ``salage'' (salt) aléatoire qui permet de s'assurer que deux condensés stockés seront toujours différents, même si leurs chaînes Fa motdepasse sont identiques.
L'argument Fa données de crypt_r est une structure de type Vt struct crypt_data . Elle contient au minimum ces champs :
struct crypt_data { char output[CRYPT_OUTPUT_SIZE]; char setting[CRYPT_OUTPUT_SIZE]; char input[CRYPT_MAX_PASSPHRASE_SIZE]; char initialized; };
Si crypt_r s'exécute avec succès, le mot de passe condensé sera stocké dans Fa output . Même si ce n'est pas obligatoire, il est recommandé dans les applications d'utiliser les champs Fa motdepasse et Fa paramètres pour stocker les chaînes qu'elles passeront à crypt_r à l'aide des arguments Fa motdepasse et Fa paramètres . Cela facilitera la suppression des données sensibles lorsqu'elles ne seront plus utilisées.
Le champ Fa initialized doit être défini à zéro avant la première utilisation d'un objet de type Vt struct crypt_data dans un appel à Fn crypt_r . Nous recommandons de définir à zéro l'objet dans son ensemble avant sa première utilisation, et non pas seulement Fa initialized et les champs documentés. (Bien entendu, il faut effectuer cette opération avant de stocker quoi que ce soit dans Fa paramètres et Fa entrée . )
L'argument Fa données de crypt_rn doit aussi pointer vers un objet de type Vt struct crypt_data , et Fa taille doit contenir la taille de ce dernier, convertie en Vt int . Lorsqu'il est utilisé avec crypt_rn l'objet Fa data dans son ensemble (à l'exception des champs Fa entrée et Fa paramètres ) doit être défini à zéro avant sa première utilisation, et cela n'est pas une simple recommandation, comme avec crypt_r Cela mis à part, les champs de l'objet s'utilisent de la même façon qu'avec crypt_r
Au premier appel à crypt_ra Fa données doit contenir l'adresse d'une variable de type Vt void * initialisée à NULL, et Fa taille l'adresse d'une variable de type Vt int initialisée à zéro. crypt_ra alloue et initialise un objet de type Vt struct crypt_data en utilisant malloc(3), et écrit son adresse et sa taille dans les variables vers lesquelles pointent respectivement Fa data et Fa taille . Ces dernières peuvent être réutilisées lors d'appels ultérieurs à crypt_ra Lorsque l'application a terminé son hachage de mots de passe, elle doit désallouer l'objet Vt struct crypt_data à l'aide de free(3).
crypt place son résultat dans une zone de mémoire statique qui sera écrasée lors d'appels ultérieurs à crypt Il n'est pas sans danger d'appeler crypt depuis plusieurs threads simultanément.
crypt_r crypt_rn et crypt_ra placent leur résultat dans le champ Fa output de leur argument Fa données . On peut sans danger les appeler depuis plusieurs threads simultanément, sous réserve qu'un objet Fa données séparé soit utilisé pour chaque thread.
En cas d'erreur, crypt_r crypt_rn et crypt_ra écrivent un mot de passe condensé non valable dans le champ Fa output de leur argument Fa données , et crypt écrit un condensé non valable dans sa zone de mémoire statique. La chaîne contiendra moins de 13 caractères, commencera par un `* ' et sera différente de Fa paramètres .
En cas d'erreur, crypt_rn et crypt_ra renvoient un pointeur NULL. crypt_r et crypt quant à elles, renverront aussi un pointeur NULL ou un pointeur vers le condensé non valable, selon la manière dont aura été configurée libcrypt. Cette possibilité de renvoyer le condensé non valable est offerte à titre de compatibilité avec les anciennes applications qui partent du principe que crypt ne peut pas renvoyer de pointeur NULL (voir Sx NOTES DE PORTABILITÉ ci-dessous).
Les quatre fonctions définissent errno en cas d'échec.
POSIX ne spécifie aucune méthode de hachage et ne requiert pas la portabilité des mots de passe condensés entre les différents systèmes. En pratique, les mots de passe condensés sont portables entre deux systèmes à partir du moment où ces derniers prennent en charge la méthode de hachage qui a été utilisée. Cependant, le jeu de méthodes de hachage prises en charge varie considérablement d'un système à l'autre.
Le comportement de crypt en cas d'erreur n'est pas bien normalisé. Certaines implémentations n'ont tout simplement pas prévu d'échouer (hormis en plantant le programme), alors que d'autres renvoient un pointeur NULL ou une chaîne prédéfinie. Certaines implémentations définissent errno mais la plupart ne le font pas. POSIX préconise de renvoyer un pointeur NULL et de définir errno mais il ne définit qu'une erreur possible, Er ENOSYS , dans le cas où crypt n'est pas du tout pris en charge. Certaines applications plus anciennes n'ont pas été conçues pour gérer les pointeurs NULL renvoyés par crypt On choisit alors le comportement décrit plus haut pour cette implémentation, à savoir définir errno et renvoyer un mot de passe condensé non valable et différent de Fa paramètres , de façon à ce que ces applications échouent en se terminant lorsqu'une erreur survient.
Suite aux restrictions historiques à l'exportation des logiciels cryptographiques depuis les USA, crypt est un composant POSIX optionnel. Les applications doivent donc prévoir l'éventualité que crypt ne soit pas disponible ou échoue systématiquement à l'exécution (en définissant errno à Er ENOSYS ) .
POSIX spécifie que crypt est déclaré dans In unistd.h, mais seulement si la macro _XOPEN_CRYPT est définie et si sa valeur est supérieure ou égale à zéro. Comme libcrypt ne fournit pas In unistd.h, elle déclare crypt crypt_r crypt_rn et crypt_ra dans In crypt.h à la place.
Sur une minorité de systèmes (en particulier les versions récentes de Solaris), crypt utilise un tampon mémoire statique spécifique aux threads qui lui permet d'être appelée sans danger depuis plusieurs threads simultanément, mais n'empêche pas chaque appel depuis un thread d'écraser les résultats de l'appel précédent.
Vt struct crypt_data peut avoir une taille assez importante (32ko dans cette implémentation de libcrypt ; plus de 128ko dans certaines autres implémentations). Cette taille est suffisamment importante pour qu'il soit malavisé de l'allouer dans la pile.
Certaines méthodes de hachage récentes nécessitent encore plus de mémoire de travail, mais l'interface crypt_r rend impossible de modifier la taille de Vt struct crypt_data sans casser la compatibilité binaire. L'interface crypt_rn pourrait accorder plus de mémoire pour certaines méthodes de hachage spécifiques, mais l'appelant de crypt_rn n'a aucun moyen de connaître la quantité de mémoire à allouer. crypt_ra effectue l'allocation de mémoire elle-même, mais ne peut effectuer qu'un seul appel à malloc(3).
Interface | Attribut | Valeur |
crypt | Sécurité des threads | MT-Unsafe race:crypt |
crypt_r crypt_rn crypt_ra | Sécurité des threads | MT-Safe |
crypt_r trouve ses origines dans la bibliothèque GNU C. Il existe aussi une fonction crypt_r sur HP-UX et dans la boîte à outils MKS, mais leurs prototype et sémantique diffèrent.
crypt_rn et crypt_ra trouvent leur origine dans le projet Openwall.
Cette traduction est une documentation libre ; veuillez vous reporter à la Lk https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à Mt debian-l10n-french@lists.debian.org Me .