web-dev-qa-db-fra.com

Pourquoi auriez-vous besoin d'un sel pour AES-CBS quand IV est déjà généré de manière aléatoire et stocké avec les données chiffrées?

Je regardais ce code et suis tombé sur ces commentaires qui disent que le chiffrement sans sel n'est pas sûr. Pourquoi serait-il dangereux lorsque vous utilisez déjà un IV aléatoire pour chaque valeur? Je pense que le commentaire est peut-être incorrect, mais c'est un joyau populaire, donc je n'en suis pas sûr. Je pense qu'il traite key vraiment comme un password, et je voulais juste vérifier.

https://github.com/attr-encrypted/encryptor/blob/master/lib/encryptor.rb#L57

  if options[:iv]
    cipher.iv = options[:iv]
    if options[:salt].nil?
      # Use a non-salted cipher.
      # This behaviour is retained for backwards compatibility. This mode
      # is not secure and new deployments should use the :salt options
      # wherever possible.
      cipher.key = options[:key]
    else
      # Use an explicit salt (which can be persisted into a database on a
      # per-column basis, for example). This is the preferred (and more
      # secure) mode of operation.
      cipher.key = OpenSSL::PKCS5.pbkdf2_hmac_sha1(options[:key], options[:salt], 2000, cipher.key_len)
    end
  else
    cipher.pkcs5_keyivgen(options[:key])
  end

J'ai l'intention d'écrire quelque chose à partir de zéro et d'utiliser uniquement des bibliothèques de base. Ma clé vient de SecureRandom.base64(32) et je vais la stocker dans le code et la décoder en Base64 pour obtenir la clé binaire, et l'utiliser pour le cryptage/décryptage, ainsi que des IV aléatoires pour chaque élément de données. Je ne pense pas avoir besoin de sel pour ça. Voudrais confirmer.

encryptionaessaltrubyinitialisation-vector
9
Chloe

Vous avez besoin de les deux un sel et un IV quand vous faites ... deux actions distinctes, l'une ayant besoin d'un sel et l'autre d'un IV. C'est votre cas ici.

Le sel concerne la transformation d'un mot de passe en un clé secrète. C'est ce qui est utilisé dans votre exemple de code: PBKDF2 est une fonction de dérivation de clé basée sur un mot de passe. Comme tout ce qui utilise des mots de passe, PBKDF2 a besoin de lenteur configurable (c'est le paramètre "2000") et aussi unicité, ce que le sel accorde. Il s'agit d'un sous-cas de hachage de mot de passe, qui est expliqué ici .

L'IV est nécessaire pour le cryptage réel. mode CBC est un algorithme séquentiel, dans lequel chaque bloc de données est d'abord XORed avec la sortie du traitement du bloc précédent. Il doit commencer quelque part ... donc l'IV est le "bloc précédent" arbitraire à utiliser pour le premier bloc.

De manière générale, le mode CBC nécessite une IV qui est uniformément aléatoire et ne peut pas être prédite par un attaquant qui est en mesure de choisir une partie des données à chiffrer (l'attaque BEAST sur SSL est de ce genre). Cependant, des problèmes surviennent uniquement lorsque la même clé est utilisée au moins deux fois. Par conséquent, les deux astuces suivantes peuvent être applicables et éviter d'avoir à transmettre un IV le long du fichier crypté:

  • PBKDF2 peut être utilisé pour générer une sortie de longueur configurable. Il est possible de générer avec PBKDF2 suffisamment d'octets pour la clé et l'IV.
  • Un IV fixe classique (par exemple "tous les zéros") est utilisé.

Les deux méthodes sont valides uniquement si la clé de chiffrement spécifique n'est utilisée qu'une seule fois. Cela signifie que si le même mot de passe est utilisé pour crypter deux fichiers, un nouveau sel aléatoire doit être généré pour chaque fichier. Ceci implique que si la transformation mot de passe en clé est coûteuse en calcul (et elle devrait l'être), et que de nombreux fichiers doivent être cryptés avec le même mot de passe, alors le coût total peut devenir prohibitif.

Si le même sel est utilisé pour plusieurs fichiers (avec le même mot de passe) (*), alors la conséquence est que la même clé sera utilisée pour tous ces fichiers, ce qui est bien ... tant que chaque fichier obtient également son propre IV. Le IV doit donc être stocké d'une manière ou d'une autre dans l'en-tête du fichier. D'un autre côté, si tous les fichiers utilisent le même sel, alors peut-être pouvez-vous mutualiser l'espace de stockage pour ce sel?

La méthode générique et sûre consiste à utiliser un IV aléatoire (généré à partir d'un PRNG cryptographiquement fort) pour chaque exécution du chiffrement , quelle que soit la façon dont la clé a été obtenue. Cela évite de faire des hypothèses implicites sur le processus de génération de clés et la fréquence à laquelle il se produit dans le protocole global. En outre, cela permet de mutualiser la transformation mot de passe en clé si de nombreux fichiers doivent être chiffrés en tant que processus par lots avec le "même mot de passe": tant que chaque fichier obtient son propre IV aléatoire, la même clé (dérivée une fois à partir du mot de passe, avec un sel) peut être appliqué en toute sécurité pour tous. C'est en quelque sorte ce qui se passe dans TLS (version 1.1 et plus): tous les records dans une connexion donnée sont cryptés avec le même clé, mais chaque enregistrement obtient son propre IV, ce qui est sûr (dans TLS 1.0, chaque enregistrement obtient son propre IV en le copiant à partir de la fin de l'enregistrement crypté précédent, qui est vulnérable à BEAST car ces IV sont alors prédictible par l'observation; dans TLS 1.1+, chaque enregistrement a un nouveau IV aléatoire spécifique).

(*) NE JAMAIS réutiliser une valeur de sel pour des mots de passe distincts. Jamais.

14
Tom Leek

Tu comprends bien. Le code que vous avez trouvé contient une erreur de nomenclature courante. à l'origine, j'ai mal lu le code. Tom Leek a raison. Le code n'est pas foiré, mais il utilise plutôt le sel lors du hachage puis plus tard en utilisant un IV lors du cryptage.

Beaucoup de gens confondent les termes "sel" et "vecteur d'initialisation". Ils servent le même objectif, mais sont techniquement utilisés dans différentes opérations. Le sel est utilisé lors du hachage, IV lors du cryptage. Dans les deux cas, le but est d'éviter que la même entrée n'aboutisse toujours à la même sortie en ajoutant une entrée aléatoire.

Si vous voyez "sel" dans le contexte du chiffrement, cela signifie probablement IV. Si vous voyez IV dans le contexte du hachage, c'est probablement le sel.

Il est important de souligner que lors du cryptage, vous devez protéger le IV. Il existe un type d'attaque dans lequel un IV non protégé peut être utilisé pour apprendre les données chiffrées. BEAST (sauf si je me souviens mal) était un exemple d'une telle attaque. Vous pouvez obtenir cette protection automatiquement en utilisant GCM, XST ou quelques autres modes de chiffrement plus récents. Si vous utilisez un mode de cryptage plus ancien comme CBC, vous devrez protéger le IV vous-même avec une signature ou un HMAC.

8
atk