Pourquoi les KDF sont-ils lents? L'utilisation d'un KDF est-elle plus sécurisée que l'utilisation du secret d'origine?
Selon la page Wikipedia pour fonctions de dérivation de clé , le but d'un KDF est de dériver une clé secrète pour la cryptographie:
En cryptographie, une fonction de dérivation de clé (KDF) dérive une ou plusieurs clés secrètes d'une valeur secrète telle qu'une clé principale, un mot de passe ou une phrase secrète à l'aide d'une fonction pseudo-aléatoire. [1] [2] Les KDF peuvent être utilisés pour étirer des clés en clés plus longues ou pour obtenir des clés d'un format requis, comme la conversion d'un élément de groupe qui est le résultat d'un échange de clés Diffie – Hellman en une clé symétrique à utiliser avec AES. Les fonctions de hachage cryptographique à clé sont des exemples populaires de fonctions pseudo-aléatoires utilisées pour la dérivation de clé. [3]
Supposons que nous venons de terminer un échange de clés Curve25519 et que nous voulons utiliser la clé pour un algorithme symétrique, par exemple AES.
- Si le secret partagé brut pouvez être utilisé comme clé pour le chiffrement symétrique, l'utilisation d'un KDF offre-t-elle des avantages en termes de sécurité? (En supposant que la sortie de KDF peut également être utilisée dans le chiffrement symétrique.
- Si le secret brut ne peut pas être utilisé comme clé pour le chiffrement, nous lui appliquons un KDF. Dans ce cas, pourquoi la KDF doit-elle être lente? (Ou cette propriété d'un KDF est-elle uniquement pour des cas spécifiques, mais pas celui-ci?)
Tous les KDF ne sont pas lents! Quelque chose comme HKDF est extrêmement rapide et n'implique qu'une poignée d'appels au PRF sous-jacent.
Les KDF ne sont lents que lorsqu'ils sont destinés à convertir une entrée potentiellement à faible entropie - comme un mot de passe - en une sortie à haute entropie telle qu'une clé de cryptage ou un vérificateur de mot de passe. Dans ce scénario, ces fonctions sont conçues pour être lentes afin d'ajouter du temps de calcul comme si l'attaquant essayait de forcer brutalement un secret avec une entropie plus élevée que celui réellement utilisé.
Pour quelque chose comme un secret partagé après un échange de clé Curve25519, vous préférez généralement un KDF rapide. Par exemple, le Noise protocol framework utilise HDKF pour générer des clés de chiffrement à partir d'un secret partagé dérivé de la multiplication de courbes. Alors que vous pouvez utiliser directement un secret partagé brut comme clé, la plupart des protocoles utilisent dans la pratique une forme de KDF pour autoriser des fonctionnalités comme le secret de retransmission.
La confusion ici est qu'il existe deux types distincts de fonction de génération de clé, et les gens disent souvent "fonction de dérivation de clé" sans être explicite sur ce qu'ils veulent dire (ou même comprendre qu'il y en a deux):
- Fonctions de dérivation de clés basées sur les clés
- Fonctions de dérivation de clé basées sur un mot de passe
Une fonction de dérivation basée sur des clés comme HKDF présuppose que les entrées peuvent être biaisées ou partiellement prévisibles, mais qu'autrement, elle a suffisamment d'entropie min pour être fiable et impossible à deviner. Le secret partagé produit par un échange Diffie-Hellman est l'un des exemples de manuels.
Les fonctions basées sur un mot de passe, en revanche, supposent que les entrées ont une faible entropie, et donc elles sont conçues pour imposer un coût aussi élevé que raisonnable à une attaque de devinettes (sans devenir insupportablement coûteux pour les parties honnêtes). Ralentir le calcul en ayant un nombre élevé d'itérations est la technique classique, mais les fonctions plus récentes comme scrypt et Argon2 vont au-delà de cela et visent à être hard-memory:
- L'algorithme canonique pour les calculer utilise une grande quantité de mémoire réglable;
- Tout algorithme pour calculer la fonction qui utilise moins de mémoire que la fonction canonique devrait payer une pénalité de temps très élevée (défavorable compromis temps-mémoire).
La raison pour laquelle vous utilisez un KDF, ou un hachage sécurisé d'ailleurs, sur une clé partagée curve25519 est que les bits ne sont pas distribués de manière aléatoire. Vous disposez de 32 octets de "données ponctuelles" qui contiennent environ 126 bits de "sécurité".
Alors ... quels morceaux choisissez-vous? Prenez les 126 premiers bits et laissez les 2 bits restants de votre clé de 128 bits à zéro? Ou prendre les 126 derniers bits? Ou simplement retirer 128 bits du milieu? Une autre stratégie? Comment savez-vous que vous avez choisi les bons morceaux? Comment savez-vous qu'il n'y a pas de modèles exploitables?
L'utilisation d'un hachage sécurisé ou de KDF résout tous ces problèmes. Quelque chose-quelque-entrée donne 128 bits de sortie à peu près parfaitement aléatoire (ou plutôt, d'aspect aléatoire). Ou, toute autre quantité de bits que vous souhaitez. Vous ne gaspillez pas l'entropie, vous n'avez pas à vous soucier de savoir si vous avez choisi les "bons" bits, et vous ne risquez pas d'avoir des modèles évidents et exploitables qui proviennent des calculs de l'ECC (qui ne sont pas parfaitement "aléatoires"). Bien sûr, l'entropie ne sera pas "magiquement" ajoutée si vous vous étirez, mais le fait est qu'un observateur externe ne peut pas dire où il se trouve. Le KDF ou le hachage n'a pas besoin d'être lent (et la plupart du temps ne devrait pas l'être ).
La raison pour laquelle vous utilisez un hachage lent ou KDF sur les mots de passe ou toute autre entrée utilisateur est que tout ce qui vient d'un humain a une entropie embarrassante et est sujet à être forcé brutalement à l'aide d'un dictionnaire (plus des permutations évidentes). Les ordinateurs modernes peuvent littéralement faire des centaines de millions de hachages simples par seconde, c'est donc un problème si votre base de données de mots de passe est volée. L'attaquant peut ne pas casser la base de données complète, mais l'obtention de quelques mots de passe d'utilisateurs ne prend qu'une fraction de seconde si aucune fonction délibérément lente n'est utilisée. Plus il faut de temps à un attaquant potentiel, mieux c'est. Plus de travail est nécessaire pour briser un mot de passe signifie que vous avez plus de temps pour réagir et informer les utilisateurs en cas de violation.
Il en va de même pour par exemple l'accès à votre disque crypté ou à votre fichier Keepass. Si un attaquant peut essayer 100 à 200 millions de mots de passe par seconde, vous pouvez tout aussi bien ne pas crypter du tout, peu importe le soin que vous accordez au choix d'un bon mot de passe.
Si un attaquant peut essayer 3-4 mots de passe par seconde parce que c'est juste combien de temps il faut pour exécuter KDF, votre mot de passe est fondamentalement "incassable" car il faut une éternité pour trouver une correspondance à ce rythme.
Certes, cela rend également plus cher le déverrouillage de votre volume. Cependant, vous ne le faites qu'une seule fois , un attaquant doit le faire plusieurs fois .