Lors du chiffrement d'un fichier avec OpenSSL, il est possible d'utiliser passe -pass: mySillyPassword, où mySillyPassword est le mot de passe utilisé dans le chiffrement. De plus, il est possible d'utiliser un sel, où -salt -s (chaîne hexadécimale) est utilisé pour spécifier le sel.
Pourquoi quelqu'un voudrait-il utiliser un mot de passe au lieu du sel ou en association avec un sel? Je comprends également que l'aide de la commande -salt provoquera OpenSSL pour générer un sel. Comment est-ce mieux qu'un sel défini par l'utilisateur? Si OpenSSL génère au hasard un sel, comment l'utilisateur de savoir ce que le sel est de décrypter le fichier dans l'avenir?
3 Réponses :
dans OpenSSL, le sel sera daté de la prévention du front des données cryptées, ce qui lui permettra d'être déchiffré. Le but du sel est d'empêcher les attaques de dictionnaires, les tables arc-en-ciel, etc. Les éléments suivants proviennent de la documentation OpenSSL:
sans l'option -salt, il est possible d'effectuer efficacement Attaques de dictionnaire sur le mot de passe et pour attaquer le flux chiffre données cryptées. La raison en est que sans le sel de la même chose Le mot de passe génère toujours la même clé de cryptage. Quand le sel est Être utilisé les huit premiers octets des données cryptées sont réservés Pour le sel: il est généré au hasard lors du cryptage d'un fichier et Lire du fichier crypté quand il est déchiffré.
La documentation suggère qu'un sel soit toujours utilisé avec un mot de passe, sauf si la compatibilité avec les versions antérieures qui ne prennent pas en charge un sel est nécessaire.
Merci pour l'explication, mais je ne comprends toujours pas le but du mot de passe. Voici ce que dit OpenSSL Documentation: Pass: mot de passe Le mot de passe réel est un mot de passe. Étant donné que le mot de passe est visible aux utilitaires (comme 'PS' sous Unix), ce formulaire ne doit être utilisé que lorsque la sécurité n'est pas importante. Comment le mot de passe est-il stocké dans les données cryptées? Est-ce annexé aussi bien? Il semble que le mot de passe n'est pas très sécurisé, mais je suppose que cela ne compte que si la personne a accès à l'ordinateur à la fois des données de temps est en cours de cryptage, correct?
Oui, vous êtes correct, le mot de passe est compromis de cette manière uniquement si l'accès à l'ordinateur existe au moment du cryptage ou du déchiffrement. Toutefois, quand il est indiqué "Ce formulaire ne doit être utilisé que lorsque la sécurité n'est pas importante", cela signifie que la syntaxe de spécification du mot de passe ( passe: mot de passe ). Au lieu de cela, vous devez utiliser d'autres méthodes, telles que le fichier : pathname ou stdin . Et non, le mot de passe n'est pas annexé. Le mot de passe est utilisé pour générer une clé secrète pour décrypter le fichier et ne peut être déchiffré qu'avec ce mot de passe. Le mot de passe est sécurisé, mais uniquement si utilisé correctement.
Merci, cela le rend plus clair. Ce mot de passe utilisé pour générer la clé secrète - est le fichier de mot de passe un fichier généré séparément? Sinon, je pense que ce serait un peu comme un sel. Je souhaite que la documentation soit plus spécifique.
Vous pouvez fournir un mot de passe dans la ligne de commande ou dans un fichier. La différence entre le mot de passe et le sel est que le mot de passe est secret, tandis que le sel n'est pas.
Merci, je comprends cette partie. Mais ma question est plus liée à l'objectif - pouvez-vous fournir un exemple de la raison pour laquelle on choisirait de renoncer à un mot de passe et d'utiliser un sel et un autre exemple de pourquoi un mot de passe serait une bonne idée?
Le but de crypter un fichier est de cacher son contenu. Ainsi, vous devez fournir un mot de passe ou une clé de cryptage. (Si vous fournissez un mot de passe, le mot de passe est utilisé pour générer une clé de cryptage, qui est ensuite utilisée pour chiffrer ou décrypter vos informations). Donc, pour répondre à votre question, non, je ne peux pas fournir d'exemple de situation dans laquelle vous utiliseriez un sel.
La touche Le mot de passe n'est jamais annexé ou codé dans le CIPHERText. En revanche, le sel est ajouté au début du ciphertext. Mais il ne peut pas être utilisé pour déchiffrer le CIPHERText sans le mot de passe. P> Pourquoi le sel est important? Imaginez que vous utilisez le même mot de passe sans sel pour chiffrer dix fichiers. Un adversaire peut générer un dictionnaire des touches pour des mots de passe potentiels, alors une fois qu'une touche décrypte un fichier, il peut décrypter tous les fichiers. Avec du sel, il doit créer dix dictionnaires différents un pour chaque sel, ce qui rend les choses plus chères pour lui et en sécurité. P> Faites des choses pratiques, j'utiliserai openssl 1.1.1: p> mot de passe sans sel: strong> p> mot de passe code> et sel code> sont deux choses différentes. Vous devez avoir un mot de passe avec ou sans sel (le mot de passe est obligatoire pendant que le sel est facultatif mais recommandé). réelle code> utilisée pour le cryptage est entraînée du mot de passe code> et du sel code>, si fourni. Par conséquent, même si le même mot de passe utilisé pour chiffrer deux fichiers, si le sel est utilisé, la clé sera différente et du cipHertext bien sûr. P> xxd enc2.salted.bin
00000000: 5361 6c74 6564 5f5f 9cfe 2d62 a2d4 70b8 Salted__..-b..p.
00000010: aee4 afb5 85c9 76a2 cb04 7e1d 27d9 94d4 ......v...~.'...
00000020: a1b3 c4d6 39b8 f5a8 c300 81b5 b6ed 4cca ....9.........L.
xxd enc1.salted.bin
00000000: 5361 6c74 6564 5f5f e73c ee5b 701b bba8 Salted__.<.[p...
00000010: fa25 c54e befa 26dc ddb1 3a2d 2bd7 a95b .%.N..&...:-+..[
00000020: bda9 56f0 4445 f229 3398 4076 1044 dad6 ..V.DE.)3.@v.D..
Le sel est important contre les adversaires qui n'utilisent pas OpenSSL / GPG pour déchiffrer votre CIPHERText. Lors de la correspondance du mot de passe (pas de la clé), un dictionnaire de dictionnaire utilisant OpenSSL décryptera tous les fichiers cryptés avec ce mot de passe, d'accord? L'objectif principal de l'adversaire ici est de connaître la norme de cryptage (AES, DES, etc.).