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.19.

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;
   

    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é.

    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.

    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és 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.17.

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.18 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.

Notes :

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é.

    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.

    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.

    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.

    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.

    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 :

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.

    armor(data bytea [ , keys text[], values text[] ]) 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.

Si les tableaux keys et values sont précisées, un entête d'armure est ajouté au format standard pour chaque paire clé/valeur. Les deux tableaux doivent avoir une seule dimension, et ils doivent avoir la même longueur. Les clés et valeurs ne peuvent pas contenir de caractères non ASCII.

pgp_armor_headers(data text, key out text, value out text) returns setof record
   

pgp_armor_headers() extrait les en-têtes d'armure à partir de data. La valeur de retour est un ensemble de lignes avec deux colonnes, une clé et une valeur. Si les clés ou valeurs contiennent des caractères non ASCII, ils sont traités avec l'encodage UTF-8.

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 probablement compression-algo et unicode-mode. Le reste doit avoir des valeurs par défaut raisonnables.

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.

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.

Lorsqu'elle est compilée avec OpenSSL 3.0.0 ou une version ultérieure, le fournisseur hérité doit être activé dans le fichier de configuration openssl.cnf pour utiliser les anciens chiffrements tels que DES or Blowfish.

Notes :

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.

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 :

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.