PostgreSQLLa base de données la plus sophistiquée au monde.

Version anglaise

F.25. pgcrypto

Le module pgcrypto propose des fonctions de cryptographie pour PostgreSQL™.

F.25.1. Fonctions de hachage généralistes

F.25.1.1. digest()

    digest(data text, type text) returns bytea
    digest(data bytea, type text) returns bytea
   

Calcule un hachage binaire de data. type est l'algorithme utilisé. Les algorithmes standards sont md5 et sha1. Si pgcrypto a été construit avec OpenSSL, d'autres algorithmes sont disponibles comme le détaille Tableau F.20, « Résumé de fonctionnalités avec et sans OpenSSL ».

Si vous voulez en résultat une chaîne hexadécimale, utilisez encode() sur le résultat. Par exemple :

    CREATE OR REPLACE FUNCTION sha1(bytea) returns text AS $$
      SELECT encode(digest($1, 'sha1'), 'hex')
    $$ LANGUAGE SQL STRICT IMMUTABLE;
   

F.25.1.2. hmac()

    hmac(data text, key text, type text) returns bytea
    hmac(data bytea, key bytea, type text) returns bytea
   

Calcule un MAC haché sur data avec la clé key. type est identique à digest().

C'est similaire à digest() mais le hachage peut être recalculé en connaissant seulement la clé. Ceci évite le scénario où quelqu'un modifie les données et le hachage en même temps.

Si la clé est plus grosse que le bloc haché, il sera tout d'abord haché puis le résultat sera utilisé comme clé.

F.25.2. Fonctions de hachage de mot de passe

Les fonctions crypt() et gen_salt() sont spécialement conçues pour hacher les mots de passe. crypt() s'occupe du hachage et gen_salt() prépare les paramètres de l'algorithme pour ça.

Les algorithmes de crypt() diffèrent des algorithmes de hachage habituels comme MD5 ou SHA1 :

  1. Ils sont lents. Comme la quantité de données est petite, c'est le seul moyen de rendre difficile la découverte par la force des mots de passe.

  2. Ils incluent une valeur aléatoire appelée sel (salt en anglais) avec le résultat, pour que les utilisateurs qui ont le même mot de passer puissent avoir des mots de passe chiffrés différents. C'est aussi une défense supplémentaire comme l'inversion de l'algorithme.

  3. Ils incluent le type de l'algorithme dans le résultat pour que les mots de passe hachés avec différents algorithmes puissent co-exister.

  4. Certains s'adaptent. Cela signifie que, une fois que les ordinateurs iront plus vite, vous pourrez configurer l'algorithme pour qu'il soit plus lent, ceci sans introduire d'incompatibilité avec les mots de passe existant.

Tableau F.17, « Algorithmes supportés par crypt() » liste les algorithmes supportés par la fonction crypt().

Tableau F.17. Algorithmes supportés par crypt()

Algorithme Longueur maximum du mot de passe Adaptif ? Bits sel Longueur de la sortie Description
bf 72 oui 128 60 Basé sur Blowfish, variante 2a
md5 unlimited non 48 34 crypt() basé sur MD5
xdes 8 oui 24 20 DES étendu
des 8 non 12 13 crypt original UNIX

F.25.2.1. crypt()

    crypt(password text, salt text) returns text
   

Calcule un hachage de mot de passe (password) d'après crypt(3) UN*X. Lors du stockage d'un nouveau mot de passe, vous devez utiliser la fonction gen_salt() pour générer un nouveau sel (salt). Lors de la vérification de mot de passe, passez la valeur hachée stockée salt, et testez si le résultat correspond à la valeur stockée.

Exemple d'ajout d'un nouveau mot de passe :

    UPDATE ... SET pswhash = crypt('new password', gen_salt('md5'));
   

Exemple d'authentification :

    SELECT (pswhash = crypt('entered password', pswhash)) AS pswmatch FROM ... ;
   

Ceci renvoie true si le mot de passe saisi est correct.

F.25.2.2. gen_salt()

    gen_salt(type text [, iter_count integer ]) returns text
   

Génère une nouvelle valeur aléatoire sel pour son utilisation avec crypt(). La chaîne sel indique aussi à crypt() l'algorithme à utiliser.

Le paramètre type précise l'algorithme de hachage. Les types acceptées sont : des, xdes, md5 et bf.

Le paramètre iter_count laisse l'utilisateur indiquer le nombre d'itération, pour les algorithmes qui en ont. Plus le nombre est important, plus le hachage du mot de passe prendra du temps, et du coup plus le craquage du mot de passe prendre du temps. Cela étant dit, un nombre trop important rend pratiquement impossible le calcul du hachage. Si le paramètre iter_count est omis, le nombre d'itération par défaut est utilisé. Les valeurs autorisées pour iter_count dépendent de l'algorithme et sont affichées dans Tableau F.18, « Nombre d'itération pour crypt() ».

Tableau F.18. Nombre d'itération pour crypt()

Algorithme Par défaut Min Max
xdes 725 1 16777215
bf 6 4 31

Pour xdes, il existe une limite supplémentaire qui fait que ce nombre doit être un nombre impair.

Pour utiliser un nombre d'itération approprié, pensez que la fonction crypt DES original a été conçu pour avoir la vitesse de quatre hachages par seconde sur le matériel de l'époque. Plus lent que quatre hachages par secondes casserait probablement la facilité d'utilisation. Plus rapide que cent hachages à la seconde est probablement trop rapide.

Tableau F.19, « Vitesse de l'algorithm de hachage » donne un aperçu de la lenteur relative de différents algorithmes de hachage. La table montre le temps que prendrait le calcul de toutes les combinaisons réalisables pour un mot de passe sur huit caractères, en supposant que le mot de passe contient soit que des lettres minuscules, soit des lettres minuscules et majuscules et des chiffres. Dans les entrées crypt-bf, le nombre après un slash est le paramètre iter_count de gen_salt.

Tableau F.19. Vitesse de l'algorithm de hachage

Algorithme Hachages/sec Pour [a-z] Pour [A-Za-z0-9]
crypt-bf/8 28 246 years 251322 years
crypt-bf/7 57 121 années 123457 années
crypt-bf/6 112 62 années 62831 années
crypt-bf/5 211 33 années 33351 années
crypt-md5 2681 2.6 années 2625 années
crypt-des 362837 7 jours 19 années
sha1 590223 4 jours 12 années
Hachage md5 2345086 1 jour 3 années

Notes :

  • La machine utilisée est un Pentium 4 à 1,5 GHz.

  • Les numéros des algorithmes crypt-des et crypt-md5 sont pris de la sortie du -test de John the Ripper v1.6.38.

  • Les nombres hachés md5 font partie de mdcrack 1.2.

  • Les nombres sha1 font partie de lcrack-20031130-beta.

  • Les nombres crypt-bf sont pris en utilisant le programme simple qui boucle sur 1000 mots de passe de huit caractères. De cette façon, je peux afficher la vitesse avec les différents nombres de tours. Pour référence : john -test affiche 213 tours/sec pour crypt-bf/5. (La petite différence dans les résultats est dû au fait que l'implémentation de crypt-bf dans pgcrypto est la même que celle utilisée dans John the Ripper.)

Notez que « tenter toutes les combinaisons » n'est pas un exercice réaliste. Habituellement, craquer les mots de passe se fait avec l'aide de dictionnaires contenant les mots standards et différentes variantes. Donc, même des mots de passe qui ressemblent vaguement à des mots peuvent être craqués plus rapidement que les nombres ci-dessus le suggèrent alors qu'un mot de passe sur six caractères qui ne ressemble pas à un mot pourrait ne pas être craqué.

F.25.3. Fonctions de chiffrement PGP

Les fonctions implémentent la partie chiffrement du standard OpenPGP (RFC 2440). Les chiffrements à clés symétriques et publiques sont supportés.

Un message PGP chiffré consiste en deux parties ou paquets :

  • Un paquet contenant la clé de session -- soit une clé symétrique soit une clé publique chiffrée.

  • Paquet contenant les données chiffrées avec la clé de session containing data encrypted with the session key.

Lors du chiffrement avec une clé symétrique (par exemple, un mot de passe) :

  1. Le mot de passe est haché en utilisant l'algorithme String2Key (S2K). C'est assez similaire à l'algorithme crypt() -- lenteur voulue et nombre aléatoire pour le sel -- mais il produit une clé binaire de taille complète.

  2. Si une clé de session séparée est demandée, une nouvelle clé sera générée au hasard. Sinon une clé S2K sera utilisée directement en tant que clé de session.

  3. Si une clé S2K est à utiliser directement, alors seuls les paramètres S2K sont placés dans le paquet de session. Sinon la clé de session sera chiffrée avec la clé S2K et placée dans le paquet de session.

Lors du chiffrement avec une clé publique :

  1. Une nouvelle clé de session est générée au hasard.

  2. Elle est chiffrée en utilisant la clé public et placée dans le paquet de session.

Dans les deux cas, les données à chiffrer sont traitées ainsi :

  1. Manipulation optionnelle des données : compression, conversion vers UTF-8, conversion de retours à la ligne.

  2. Les données sont préfixées avec un bloc d'octets pris au hasard. C'est identique à l'utilisation de random IV.

  3. Un hachage SHA1 d'un préfixe et de données au hasard est ajouté.

  4. Tout ceci est chiffré avec la clé de la session et placé dans la paquet de données.

F.25.3.1. pgp_sym_encrypt()

    pgp_sym_encrypt(data text, psw text [, options text ]) returns bytea
    pgp_sym_encrypt_bytea(data bytea, psw text [, options text ]) returns bytea
   

Chiffre data avec une clé PGP symétrique psw. Le paramètre options peut contenir des options décrites ci-dessous.

F.25.3.2. pgp_sym_decrypt()

    pgp_sym_decrypt(msg bytea, psw text [, options text ]) returns text
    pgp_sym_decrypt_bytea(msg bytea, psw text [, options text ]) returns bytea
   

Déchiffre un message PGP chiffré avec une clé symétrique.

Déchiffrer des données bytea avec pgp_sym_decrypt est interdit. Ceci a pour but d'éviter la sortie de données de type caractère invalides. Déchiffrer des données textuelles avec pgp_sym_decrypt_bytea ne pose pas de problème.

Le paramètre options peut contenir les paramètres décrits ci-dessous.

F.25.3.3. pgp_pub_encrypt()

    pgp_pub_encrypt(data text, key bytea [, options text ]) returns bytea
    pgp_pub_encrypt_bytea(data bytea, key bytea [, options text ]) returns bytea
   

Chiffre data avec la clé PGP publique key. Avec cette fonction, une clé privée renverra une erreur.

Le paramètre options peut contenir des options décrites ci-dessous.

F.25.3.4. pgp_pub_decrypt()

    pgp_pub_decrypt(msg bytea, key bytea [, psw text [, options text ]]) returns text
    pgp_pub_decrypt_bytea(msg bytea, key bytea [, psw text [, options text ]]) returns bytea
   

Déchiffre un message chiffré avec une clé publique. key doit être la clé secrète correspondant à la clé publique utilisée pour chiffrer. Si la clé secrète est protégée par un mot de passe, vous devez saisir le mot de passe dans psw. S'il n'y a pas de mot de passe mais que vous devez indiquer des options, vous devez saisir un mot de passe vide.

Déchiffrer des données bytea avec pgp_pub_decrypt est interdit. Ceci a pour but d'éviter la sortie de données de type caractère invalides. Déchiffrer des données textuelles avec pgp_pub_decrypt_bytea ne pose pas de problème.

Le paramètre options peut contenir des options décrites ci-dessous.

F.25.3.5. pgp_key_id()

    pgp_key_id(bytea) returns text
   

pgp_key_id extrait l'identifiant de la clé pour une clé PGP publique ou secrète. Ou il donne l'identifiant de la clé utilisé pour chiffrer les données si un message chiffré est fourni.

Elle peut renvoyer deux identifiants de clés spéciaux :

  • SYMKEY

    Le message est chiffré avec une clé symétrique.

  • ANYKEY

    La donnée est chiffrée avec une clé publique mais l'identifiant de la clé est effacé. Cela signifie que vous avez besoin d'essayer toutes les clés secrètes pour voir laquelle la déchiffre. pgcrypto ne réalise pas lui-même de tels messages.

Notez que des clés différentes peuvent avoir le même identifiant. C'est rare mais normal. L'application client doit alors essayer de déchiffer avec chacune d'elle pour voir laquelle correspond -- ce qui revient à la gestion de ANYKEY.

F.25.3.6. armor(), dearmor()

    armor(data bytea) returns text
    dearmor(data text) returns bytea
   

Ces fonctions enveloppent les données dans une armure ASCII PGP qui est basiquement en Base64 avec CRC et un formatage supplémentaire.

F.25.3.7. Options pour les fonctions PGP

Les options sont nommées de façon similaires à GnuPG. Les valeurs sont fournies après un signe d'égalité ; les options sont séparées par des virgules. Par exemple :

    pgp_sym_encrypt(data, psw, 'compress-algo=1, cipher-algo=aes256')
   

Toutes les options en dehors de convert-crlf s'appliquent seulement aux fonctions de chiffrement. Les fonctions de déchiffrement obtiennent des paramètres des données PGP.

Les options les plus intéressantes sont problablement compression-algo et unicode-mode. Le reste doit avoir des valeurs par défaut raisonnables.

F.25.3.7.1. cipher-algo

Quel algorithme de chiffrement à utiliser.


    Valeurs : bf, aes128, aes192, aes256 (OpenSSL seulement :
    3descast5)
    Par défaut : aes128
    Applique à : pgp_sym_encrypt, pgp_pub_encrypt
   

F.25.3.7.2. compress-algo

Algorithme de compression à utiliser. Seulement disponible si PostgreSQL™ a été construit avec zlib.


    Valeurs :
      0 - sans compression
      1 - compression ZIP
      2 -  compression ZLIB [=ZIP plus meta-data and block-CRC's]
    Par défaut : 0
    S'applique à : pgp_sym_encrypt, pgp_pub_encrypt
   

F.25.3.7.3. compress-level

Niveau de compression. Les grands niveaux compressent mieux mais sont plus lents. 0 désactive la compression.


    Valeurs : 0, 1-9
    Par défaut : 6
    S'applique à : pgp_sym_encrypt, pgp_pub_encrypt
   

F.25.3.7.4. convert-crlf

Précise si \n doit être converti en \r\n lors du chiffrement et \r\n en \n lors du déchiffrement. La RFC 4880 spécifie que les données texte doivent être stockées en utilisant les retours chariot \r\n. Utilisez cette option pour obtenir un comportement respectant la RFC.


    Valeurs : 0, 1
    Par défaut : 0
    S'applique à : pgp_sym_encrypt, pgp_pub_encrypt, pgp_sym_decrypt,
    pgp_pub_decrypt
   

F.25.3.7.5. disable-mdc

Ne protège pas les données avec SHA-1. La seule bonne raison pour utiliser cette option est d'avoir une compatibilité avec les anciens produits PGP précédant l'ajout de paquets protégés SHA-1 dans la RFC 4880. Les versions récentes des logiciels de gnupg.org et pgp.com le supportent.


    Valeurs : 0, 1
    Par défaut : 0
    S'applique à : pgp_sym_encrypt, pgp_pub_encrypt
   

F.25.3.7.6. sess-key

Utilise la clé de session séparée. Le chiffrement par clé publique utilise toujours une clé de session séparée, c'est pour le chiffrement de clé symétrique, qui utilise directement par défaut S2K.


    Valeurs : 0, 1
    Par défaut : 0
    S'applique à : pgp_sym_encrypt
   

F.25.3.7.7. s2k-mode

Algorithme S2K à utiliser.


    Valeurs :
      0 - Sans sel. Dangereux !
      1 - Avec sel mais avec un décompte fixe des itérations.
      3 - Décompte variables des itérations.
    Par défaut : 3
    S'applique à : pgp_sym_encrypt
   

F.25.3.7.8. s2k-digest-algo

Algorithme digest à utiliser dans le calcul S2K.


    Valeurs : md5, sha1
    Par défaut : sha1
    S'applique à : pgp_sym_encrypt
   

F.25.3.7.9. s2k-cipher-algo

Chiffrement à utiliser pour le chiffrage de la clé de session séparée.


    Valeurs : bf, aes, aes128, aes192, aes256
    Par défaut : use cipher-algo
    S'applique à : pgp_sym_encrypt
   

F.25.3.7.10. unicode-mode

Sélection de la conversion des données texte à partir de l'encodage interne de la base vers l'UTF-8 et inversement. Si votre base de données est déjà en UTF-8, aucune conversion ne sera réalisée, seules les données seront marquées comme étant en UTF-8. Sans cette option, cela ne se fera pas.


    Valeurs : 0, 1
    Par défaut : 0
    S'applique à : pgp_sym_encrypt, pgp_pub_encrypt
   

F.25.3.8. Générer des clés PGP avec GnuPG

Pour générer une nouvelle clé :

   gpg --gen-key
  

Le type de clé préféré est « DSA and Elgamal ».

Pour le chiffrement RSA, vous devez créer soit une clé de signature seulement DSA ou RSA en tant que maître, puis ajouter la sous-clé de chiffrement RSA avec gpg --edit-key.

Pour lister les clés :

   gpg --list-secret-keys
  

Pour exporter une clé publique dans un format armure ASCII :

   gpg -a --export KEYID > public.key
  

Pour exporter une clé secrète dans un format armure ASCII :

   gpg -a --export-secret-keys KEYID > secret.key
  

Vous avez besoin d'utiliser la fonction dearmor() sur ces clés avant de les passer aux fonctions PGP. Ou si vous gérez des données binaires, vous pouvez supprimer l'option -a pour la commande.

Pour plus de détails, voir la page de référence de gpg, le livre « GNU Privacy Handbook » et d'autres documents sur le site gnupg.org.

F.25.3.9. Limites du code PGP

  • Pas de support des signatures. Cela signifie aussi qu'on ne peut pas vérifier si la sous-clé de chiffrage appartient bien à la clé maître.

  • Pas de support de la clé de chiffrement en tant que clé maître. Cela ne devrait pas être un problème étant donné que cette pratique n'est pas encouragée.

  • Pas de support pour plusieurs sous-clés. Ceci peut être un problème car c'est une pratique courante. D'un autre côté, vous ne devez pas utiliser vos clés GPG/PGP habituelles avec pgcrypto, mais en créer de nouvelles car l'utilisation est assez différente.

F.25.4. Fonctions de chiffrement brut (Raw)

Ces fonctions exécutent directement un calcul des données ; ils n'ont pas de fonctionnalités avancées de chiffrement PGP. Du coup, ils ont les problèmes majeurs suivant :

  1. Elles utilisent directement la clé de l'utilisateur comme clé de calcul.

  2. Elles ne fournissent pas une vérification de l'intégrité pour savoir si les données chiffrées ont été modifiées.

  3. Elles s'attendent à ce que les utilisateurs gèrent eux-même tous les paramètres du chiffrement, même IV.

  4. Elles ne gèrent pas le texte.

Donc, avec l'introduction du chiffrement PGP, l'utilisation des fonctions de chiffrement brut n'est pas encouragée.

    encrypt(data bytea, key bytea, type text) returns bytea
    decrypt(data bytea, key bytea, type text) returns bytea

    encrypt_iv(data bytea, key bytea, iv bytea, type text) returns bytea
    decrypt_iv(data bytea, key bytea, iv bytea, type text) returns bytea
  

Chiffrer/déchiffrer les données en utilisant la méthode de calcul spécifiée par type. La syntaxe de la chaîne type est :

   algorithm [ - mode ] [ /pad: padding ]
  

algorithm fait partie de :

  • bf -- Blowfish

  • aes -- AES (Rijndael-128, -192 ou -256)

et mode fait partie de :

  • cbc -- le bloc suivant dépend du précédent. (par défaut)

  • ecb -- chaque bloc est chiffré séparément. (seulement pour les tests)

et padding fait partie de :

  • pkcs -- les données peuvent avoir n'importe quelle longueur (par défault)

  • none -- les données doivent être des multiples de la taille du bloc de calcul.

Donc, pour exemple, ces derniers sont équivalents :

   encrypt(data, 'fooz', 'bf')
   encrypt(data, 'fooz', 'bf-cbc/pad:pkcs')
  

Dans encrypt_iv et decrypt_iv, le paramètre iv est la valeur initiale pour le mode CBC ; elle est ignorée pour ECB. Elle est remplie de zéro pour l'alignement si la taille de données ne correspond à un multiple de la taille du bloc. It defaults to all zeroes in the functions without this parameter.

F.25.5. Fonctions d'octets au hasard

   gen_random_bytes(count integer) returns bytea
  

Renvoie count) octets pour un chiffrement fort. Il peut y avoir au maximum 1024 octets extrait à un instant t, ceci pour éviter de vider le contenu du générateur de nombres aléatoires.

F.25.6. Notes

F.25.6.1. Configuration

pgcrypto se configure lui-même suivant les découvertes du scrip configure principal de PostgreSQL. Les options qui l'affectent sont --with-zlib et --with-openssl.

Quand il est compilé avec zlib, les fonctions de chiffrement PGP peuvent compresser les données avant chiffrement.

Quand il est compilé avec OpenSSL, plus d'algorithmes seront disponibles. De plus, les fonctions de chiffrement à clé publique seront plus rapides car OpenSSL a des fonctions BIGNUM plus optimisées.

Tableau F.20. Résumé de fonctionnalités avec et sans OpenSSL

Fonctionnalité Interne Avec OpenSSL
MD5 oui oui
SHA1 oui oui
SHA224/256/384/512 oui oui (Note 1)
D'autres algorithmes digest non oui (Note 2)
Blowfish oui oui
AES oui oui (Note 3)
DES/3DES/CAST5 non oui
Raw encryption oui oui
PGP Symmetric encryption oui oui
PGP Public-Key encryption oui oui

Notes :

  1. Les algorithmes SHA2 ont été ajoutés à OpenSSL version 0.9.8. Pour les anciennes versions, pgcrypto utilisera du code interne.

  2. Tout algorithme digest qu'OpenSSL supporte est automatiquement choisi. Ce n'est pas possible avec les chiffreurs qui doivent être supportés explicitement.

  3. AES est inclus dans OpenSSL depuis la version 0.9.7. Pour les anciennes versions, pgcrypto utilisera du code interne.

F.25.6.2. Gestion des NULL

Comme le standard SQL le demande, toutes les fonctions renvoient NULL si un des arguments est NULL. Cela peut permettre une faille de sécurité si c'est utilisé sans précaution.

F.25.6.3. Limites de la sécurité

Toutes les fonctions de pgcrypto sont exécutées au sein du serveur de bases de données. Cela signifie que toutes les données et les mots de passe sont passés entre pgcrypto et l'application client en texte clair. Donc, vous devez :

  1. Vous connecter localement ou utiliser des connexions SSL ;

  2. Faire confiance à votre administrateur système et de base de données.

Si vous ne le pouvez pas, alors il est préférable de chiffrer directement au sein de l'application client.

L'implémentation ne résiste pas à des attaques par canal auxiliaire. Par exemple, le temps requis pour terminer l'exécution d'une fonction de déchiffrement de pgcrypto varie suivant les texts de déchiffrement d'une certaine taille.

F.25.6.4. Lectures intéressantes

F.25.6.5. Références tecyhniques

F.25.7. Auteur

Marko Kreen

pgcrypto utilise du code provenant des sources suivantes :

Algorithme Auteur Origine du source
DES crypt David Burren and others FreeBSD libcrypt
MD5 crypt Poul-Henning Kamp FreeBSD libcrypt
Blowfish crypt Solar Designer www.openwall.com
Blowfish cipher Simon Tatham PuTTY
Rijndael cipher Brian Gladman OpenBSD sys/crypto
Hachage MD5 and SHA1 WIDE Project KAME kame/sys/crypto
SHA256/384/512 Aaron D. Gifford OpenBSD sys/crypto
BIGNUM math Michael J. Fromberger dartmouth.edu/~sting/sw/imath