Question:
Les archives partagées protégées par mot de passe 7-Zip sont-elles sûres contre les pirates informatiques lorsqu'elles sont protégées par mot de passe plusieurs fois?
Neli
2017-03-24 18:10:18 UTC
view on stackexchange narkive permalink

Imaginez que je souhaite télécharger mes informations personnelles sensibles (photos, numérisations de documents, liste de mots de passe, sauvegardes d'e-mails, informations de carte de crédit, etc.) sur Google Drive (ou tout autre service cloud).

Je veux m'assurer que tout ce tas de données est aussi sûr que possible (contre les pirates informatiques qui d'une certaine manière mettre la main sur ces données, et contre Google et ses employés, et aussi à l'avenir, c'est-à-dire si je supprime ces données de Google Je veux être sûr qu'ils ne pourront pas «l'ouvrir» même s'ils gardent sa sauvegarde pour toujours).

Donc, dans ce cas, au lieu de télécharger toutes ces données tout de suite dans le cloud, je créera à la place un dossier contenant toutes les données que je souhaite télécharger, puis je compresserai ce dossier entier en utilisant 7-Zip et bien sûr en le protégeant par mot de passe en utilisant 7-Zip.

Je ne le ferai pas une fois, mais quelques fois, c'est-à-dire une fois que l'archive protégée par mot de passe 7-Zip est prête, je la compresse à nouveau en utilisant 7-Zip et j'utilise un mot de passe complètement différent. Je vais le faire cinq fois. Donc, à la fin, mes données sont compressées cinq fois et elles ont été protégées par mot de passe à l'aide de 7-Zip par cinq mots de passe complètement différents et indépendants. Donc, pour accéder à mes données, je dois les extraire cinq fois et fournir cinq mots de passe différents.

Ce que je ferai ensuite, c'est que je prendrai cette archive protégée par mot de passe cinq fois, et Je vais le compresser à nouveau en utilisant 7-Zip et encore un sixième mot de passe différent, mais en plus de cela cette fois, je choisirai également de diviser l'archive en plus petits morceaux.

Disons qu'à la fin je termine avec 10 archives séparées, où chacune d'elles est une archive de 200 Mo sauf la 10e étant seulement une archive de 5 Mo.

L'hypothèse est que tous ces six mots de passe sont des mots de passe d'au moins 32 caractères et ils sont totalement indépendants et contiennent tous des minuscules / majuscules, des chiffres et des symboles.

Je prends maintenant ces neuf archives de 200 Mo, je les place dans un conteneur et je crypte le conteneur à l'aide de VeraCrypt (en supposant le cryptage en cascade à trois niveaux), puis je télécharge ce conteneur sur mon Google Drive.

Je garde la 10e archive (celle de 5 Mo) sur un service complètement différent (disons sur Dropbox - et ce compte Dropbox n'est en aucun cas connecté / lié à mon compte Google) (également crypté par VeraCrypt ).

- Ai-je créé un théâtre de sécurité? Ou ai-je vraiment rendu impossible l'accès et l'extraction de mes données à quiconque? Après tout, ils doivent passer un niveau de cryptage par VeraCrypt et même après cela, les archives sont six fois protégées par mot de passe et l'une des archives (la dixième) est stockée ailleurs!

- Si quelqu'un accède à mon Google Drive et télécharge toutes ces neuf archives, y a-t-il un moyen d'extraire l'archive sans avoir la dernière (la dixième) archive de 5 Mo? Les données peuvent-elles être accessibles de quelque manière que ce soit avec l'une des archives fractionnées manquantes?

- Même si quelqu'un met la main sur toutes ces 10 archives ensemble et parvient à contourner le VeraCrypt chiffrement de quelque manière que ce soit, sera-t-il toujours possible de casser les six mots de passe restants?

Vous compliquez trop les choses et la complexité est un ennemi de la sécurité.7zip a un cryptage natif AES-256 bits, donc un seul mot de passe fort et unique devrait suffire.Même si vous êtes aussi intéressant pour quelqu'un qui pourrait potentiellement déchiffrer ce cryptage que vous le pensez, il y a de fortes chances qu'il essaie de vous cibler pendant que vous traitez les données et non quand il est au repos, car c'est le chemin de moindre résistance.
Ceci bien sûr entièrement hypothétique et une question d'intérêt personnel, je comprends que la plupart des pirates informatiques ne s'approcheront même plus de ce type de données personnelles lorsqu'ils prendront conscience qu'elle est fortement cryptée et que l'effort ne vaut pas du tout la récompense.Mais je souhaite toujours savoir si ce cas hypothétique offrirait un niveau de sécurité plus élevé et un casse-tête énorme pour un hacker professionnel décent et trop expérimenté.
@DKNUCKLES "qui pourrait potentiellement casser ce cryptage" Pour le moment, très probablement personne ne peut craquer AES.Mais il est probable que quelqu'un sera capable de le casser 30 à 40 ans dans le futur.Je crois que c'est ce qu'OP voulait dire par "aussi sûr que possible (...) également dans le futur".
Je tiens également à faire remarquer que Google et peut-être d'autres entreprises disposent de ressources pour créer des clusters de calcul forcés par hachage multi-GPU.Voir [link] (http://www.eweek.com/security/researchers-from-google-cti-break-sha-1-hash-encryption-function) suggérant d'utiliser la plus longue phrase de passe possible.
Une chose évidente que je n'ai pas vue mentionnée dans les réponses est que * deviner trois mots de passe d'un bit chacun est beaucoup plus facile que de deviner un seul mot de passe à trois bits (via bruteforce) *.En d'autres termes, un mot de passe plus long est plus robuste que beaucoup de plus petits car il n'y a pas de rétroaction intermédiaire dont on puisse tirer parti.
J'envisagerais d'utiliser tresorit au lieu de par ex.Google Drive.C'est déjà un service cloud chiffré de bout en bout avec une politique de connaissance zéro du côté de l'entreprise.
Le ** dernier ** élément d'une archive manquant est vraiment le cas le plus facile à vaincre, en supposant un chiffrement par block chaining - cela n'empêchera pas les gens d'extraire du contenu des autres s'ils sont prêts à écrire un peu deleur propre code.Si vous voulez garder une pièce dans un endroit plus difficile d'accès, faites-en la * première *.(Cela dit, je suis entièrement d'accord avec les évaluations du "théâtre de sécurité inutile").
Notez que l'utilisation de 5 mots de passe de longueur X est nettement pire que d'utiliser un mot de passe de 5 * X longueur.C'est comme si je vous demandais deux fois de suite de deviner un nombre entre 0 et 10, ce qui prendrait au plus 20 suppositions, par rapport à deviner un seul nombre entre 00 et 99. Si votre mot de passe longueur X donnait par exemple 2 ^ 25 combinaisons,puis craquer votre schéma impliquerait de le faire 5 fois, donc faire 5 * 2 ^ 25 ~ 2 ^ 27 quantité de travail.Mais au lieu de cela, créer un mot de passe 5 * X donnerait 2 ^ 25 * 2 ^ 25 * 2 ^ 25 * 2 ^ 25 * 2 ^ 25 = 2 ^ 125 quantité de travail.
@epa095 Je ne pense pas que ce soit correct.Vous supposez que l'attaquant peut briser les couches "une par une" (c'est-à-dire qu'il devine le premier nombre 0-10, puis, après avoir correctement deviné celui-là, devine l'autre).Cependant, un fichier crypté ne contient pratiquement que des données aléatoires, de sorte que l'attaquant brise tous les cryptages en une seule fois, ou aucun d'entre eux.(Parce qu'il n'a aucun moyen de dire s'il a correctement cassé une seule couche de cryptage) C'est comme deviner deux nombres 0-10 * mais avoir à dire les deux nombres en même temps *, ce qui nécessite 100 essais pour être résolu avec certitude.
@Bakuriu: Oui, je suppose que l'attaqué peut briser chaque couche par lui-même, ce qui est exactement la situation dans laquelle nous nous trouvons ici.La suggestion est d'utiliser 7-Zip et d'itérer la fermeture éclair avec différents mots de passe, 5 fois.Ensuite, vous êtes certainement en mesure de distinguer si vous avez réussi à déchiffrer le mot de passe «externe» ou non.Une archive 7-zip contient plus que les données brutes, elle possède également des champs de métadonnées qui vous permettent de reconnaître si votre tentative de décryptage du zip externe a réussi.Si je saisis un mauvais mot de passe, 7-zip est capable de le détecter et de fournir une erreur.
N'oubliez pas de cocher l'option * "Crypter les noms de fichiers" * (qui n'est pas activée par défaut).Sinon, vous ferez une fuite d'informations en exposant *** tous les *** noms de dossiers et de fichiers ...
[XKCD obligatoire] (https://xkcd.com/538/)
Huit réponses:
Philipp
2017-03-24 18:26:11 UTC
view on stackexchange narkive permalink

Tout d'abord, ce schéma de multi-cryptage est ridicule.

L'algorithme utilisé par 7-Zip est AES-256 qui est considéré comme sécurisé. Mais si quelqu'un y trouvait une faille qui la rendrait cassable, alors il serait probablement capable de casser toutes vos couches de cryptage avec le même effort.

Donc, soit vous faites confiance à l'algorithme de cryptage utilisé par 7-Zip , une seule application suffirait. Ou vous ne lui faites pas confiance, alors vous feriez une autre passe de cryptage avec un algorithme différent . La superposition du même algorithme plusieurs fois n'a souvent pas autant d'effet qu'on pourrait le penser, comme l'a démontré l'attaque du milieu contre Triple-DES.

À propos de fractionnement d'un fichier chiffré: il est souvent possible de récupérer certaines données d'une archive 7-Zip si des parties de l'archive sont manquantes. 7-Zip utilise AES en mode CBC pour émuler le comportement de chiffrement de flux (chaque bloc de 128 bits est combiné avec le bloc de 128 bits précédent). Cela signifie que si quelqu'un manque une partie du message, il ne peut pas décrypter ce qui suit (à moins d'avoir un texte en clair connu quelque part), mais tout ce qui précède. Cela signifie que si vous voulez empêcher un attaquant de déchiffrer l'archive en en retenant une partie, vous devez retenir le premier morceau, pas le dernier.

Informations intéressantes et utiles.Vous faites remarquer que "[...] ils seraient probablement capables de briser toutes vos couches de chiffrement avec le même effort."C'est en fait une question profondément ancrée dans mon enquête: vous dites avec un effort «égal».Ainsi, par exemple, s'il leur faut 10 mois pour briser ce cryptage, alors un effort égal signifie qu'ils devraient passer 50 mois de plus pour casser le reste des mots de passe.Donc, dans ce scénario, le multi-cryptage a été bénéfique.N'est-ce pas vrai?
@Neli: Uniquement si cassé par force brute.S'ils peuvent casser le premier dans 10 mois via une autre méthode, il leur faudra ~ 0 mois de plus pour casser le reste des mots de passe.
C'est l'attaque de la rencontre au milieu déjà mentionnée, donc en fonction de la façon dont elle est cassée, ils pourraient devoir effectuer une opération 5 fois, ou ils pourraient effectuer une opération une fois et obtenir une clé à la fin qui correspond à vos 5 clés combinées en une seule.
@Neli C'est * un * exemple, mais pas le seul.Vous devez également tenir compte d'événements tels que quelqu'un qui a totalement vaincu le cryptage 7zip.Par exemple parce que 7zip a une implémentation backdoor ou parce que (très peu probable) quelqu'un découvre une faille dans AES qui le rend trivialement cassable.Si votre seul objectif est d'attendre l'heure du forçage brutal, vous pouvez obtenir de meilleurs résultats en utilisant un algorithme avec une longueur de clé plus longue et en utilisant une phrase secrète plus longue.
Cette réponse est incorrecte en ce qui concerne les [attaques de rencontre du milieu] (https://en.wikipedia.org/wiki/Meet-in-the-middle_attack), qui sont irréalisables contre des clés de 256 bits en raison de l'astronomiequantité de stockage nécessaire pour effectuer une telle attaque.
@Nat, le commentaire de l'attaque de la rencontre du milieu concernait spécifiquement 3DES.
@Philipp Cela n'a aucun rapport avec la superposition de l'AES-256 et cette question en général.
@Neli cette augmentation de temps ne semble attrayante que jusqu'à ce que vous vous rendiez compte que l'ajout d'un seul caractère au mot de passe augmentera le temps de force brute d'environ 300 à 800 mois (selon la classe de caractère que vous choisissez).Donc, en termes de nombre de personnages que vous devez mémoriser par rapport à la force contre la force brute, faire plusieurs passes est une approche particulièrement pauvre.
@Neli Une autre façon de voir les choses est de considérer la loi de Moore.Si cela continue, nous doublons (à peu près) notre puissance de calcul tous les 1,5 ans.Donc, s'il fallait 10 mois pour casser le cryptage à une date donnée, cela prendrait 10 mois pour casser votre système à 6 couches 3,8 ans plus tard.Et, bien sûr, il faudrait 5 mois pour briser l'ensemble du système à 6 couches en 5,3 ans.Et cela suppose * littéralement * le meilleur des cas (c'est-à-dire aucun exploit trouvé)
Étude de cas sur les exploits: les hachages MD5 étaient considérés comme sécurisés.On pensait que toutes les ressources informatiques du monde ne pouvaient pas créer une seule collision dans la vie de la race humaine.C'était en 92 quand il a été inventé.De nos jours, comme l'algorithme a été cassé, il faut maintenant 11 heures pour générer une collision de votre choix.Si vous superposiez 500 de ces hachages MD5 les uns sur les autres, cela ne prendrait encore qu'un an pour se casser.
La loi de Moore est morte depuis longtemps.La prochaine mise à niveau du processeur donne peut-être quelques centaines de MHz supplémentaires, peut-être même quelques dizaines.Dans le passé, lorsque la loi de Moore s'appliquait encore, un processeur de 3,5 MHz était remplacé par un processeur de 16 MHz.Imaginez si votre processeur 3,2 GHz était remplacé quelques années plus tard par un processeur 14,6 GHz!Si seulement...
Notez également que l'explication d'@Tgr's est vraiment au cœur du problème.Si vous avez un mot de passe avec 80 bits d'entropie, il vaut bien mieux l'allonger de 80 bits supplémentaires que d'ajouter une autre "couche" de cryptage avec sa propre clé de 80 bits.La différence se situe entre l'exponentiation et la multiplication.Doubler la longueur d'un mot de passe pour un seul chiffrement augmente la force de 2 ^ (n * 2).Le doublement des couches de chiffrement (même augmentation exacte de la taille du mot de passe) n'augmente la force que de 2 ^ n * 2.Évidemment, le premier est bien meilleur!
A. Hersean
2017-03-24 18:29:49 UTC
view on stackexchange narkive permalink

C'est de l'ingénierie à une échelle que je n'ai jamais vue. C'est une MAUVAISE CHOSE car cela augmente la complexité de votre solution sans ajouter aucun avantage en matière de sécurité.

Le mécanisme de chiffrement est soit sûr, soit il ne l'est pas. Vous ne serez pas plus protégé en cryptant plusieurs fois. Si le cryptage est sécurisé, il est inutile d'ajouter des couches de cryptage supplémentaires. S'il y a une faille dans votre modèle de sécurité, par exemple, vos clés de chiffrement pourraient fuir, plusieurs couches de chiffrement ne corrigeront pas cette faille.

C'est la même chose pour le fractionnement de l'archive: cela ne sert à rien. Cela n'améliore ni ne diminue la protection de vos documents.

Vous devriez avoir une vue d'ensemble: où enregistrez-vous votre phrase secrète? Qui peut y accéder? Quelle est votre solution de sauvegarde si vous ne pouvez pas accéder ou vous souvenir de votre phrase secrète? Votre ordinateur est-il à l'abri des logiciels malveillants (qui rendraient tout cryptage inutile)? Votre solution est-elle si complexe que vous ne l’utiliserez jamais?

* Vous ne serez pas plus protégé en cryptant plusieurs fois. * => Je pense qu'il y a deux mises en garde avec cette déclaration: (1) si certains mots de passe conduisent à des clés faibles (éventuellement), l'utilisation de plusieurs couches le rend moins susceptible de se produire accidentellementfrapper une clé faible et (2) chiffrer plusieurs fois * avec différents algorithmes * protégerait mieux contre l'un d'eux ayant une faille.Bien sûr, étant donné qu'AES256 est considéré comme sûr, tout dépend de l'existence (maintenant ou dans le futur) d'une faiblesse dans AES256.
Je suppose des algorithmes sécurisés.Si vous utilisez des mots de passe faibles, il y a de fortes chances que tous vos mots de passe soient faibles, donc la sécurité ne s'améliorera pas considérablement avec plusieurs couches de cryptage (je vous laisse faire le calcul).
Je ne parle PAS de mots de passe faibles, je parle de mots de passe menant à une clé AES256 faible, similaire au problème qui tourmentait [DES] (http://crypto.stackexchange.com/questions/12214/can-you-explain-faibles-clés-pour-des).
Le but du fractionnement était de rendre l'archive inextractible de manière simple.C'est-à-dire que si vous avez 10 archives et que l'une d'entre elles est manquante, et que vous avez le mot de passe, il n'y a pas de moyen facile dans 7zip lui-même d'extraire ces données.Ainsi, j'ai supposé que cela pourrait ajouter un certain niveau de sécurité.
@matthieu-m Vous devrez utiliser ces mots de passe exprès.S'ils existent pour AES, ils seront vraiment difficiles à trouver.Vous ne pouvez pas en utiliser un de manière réaliste.Faites le calcul.
@Neli Si un gestionnaire d'attaquant trouve 9 archives sur 10, pensez-vous vraiment qu'il ne pourra pas trouver celle qui manque?Et s'il ne le fait pas, il pourrait encore déchiffrer certains des 9 qu'il a (parce que vous pensez que le cryptage est faible, cela signifie qu'un attaquant peut le casser dans votre modèle de sécurité).Vous serez mieux servi en utilisant un seul schéma de cryptage fort avec une bonne politique de sécurité pour protéger les secrets (la clé ou le mot de passe).
Si un attaquant tente de le forcer brutalement, le fait d'avoir plusieurs cryptages ne sera-t-il pas bénéfique dans ce cas?(bénéfique = ralentir beaucoup l'attaquant) Un principe similaire à la façon dont PBKDF2 le fait.
Le forçage brutal @razu-murzea 9 fois plus est plus rapide que le forçage brutal d'un mot de passe avec un caractère aléatoire ajouté.PBKDF2 ne dérive pas seulement le mot de passe 10 fois.Augmentez simplement la longueur de votre mot de passe et vous serez mieux protégé qu'en augmentant la complexité de votre schéma de cryptage.
Cort Ammon
2017-03-25 04:50:39 UTC
view on stackexchange narkive permalink

Tout d'abord, respirez. Les efforts de cryptage échouent souvent si vous oubliez de respirer. Quelque chose à propos de l'inconscience nous amène à avoir du mal à chiffrer les choses!

Deuxièmement, il semble que vous ayez besoin d'un modèle de menace. Un modèle de menace décrit le type d'adversaires que vous craignez d'affronter. Sans modèle de menace, toute sécurité est un théâtre de sécurité car vous vous débattez en espérant que vos actions incontrôlées arrêteront un adversaire dont vous ne savez rien. Essayez-vous d'empêcher votre sœur de lire votre journal, ou essayez-vous de vous cacher de la foule? Vous êtes-vous fait des ennemis avec des agences à trois lettres ces derniers temps?

Avez-vous réfléchi à la volonté de votre adversaire de se lancer dans une analyse cryptographique avec des tuyaux en caoutchouc?

XKCD ( XKCD)

C'est pourquoi un modèle de menace est si essentiel. Considère ceci. Il est généralement admis qu'un fichier crypté AES-256 protégé par un mot de passe suffisamment long est incassable par quoi que ce soit sauf une agence gouvernementale, et son généralement suppose que les agences gouvernementales ne peuvent pas non plus le casser. Ainsi, une seule couche d'AES-256 vous protégera très certainement de tout, jusqu'aux types de personnages louches qui sont prêts à vous battre avec un tuyau en caoutchouc jusqu'à ce que vous crachiez le mot de passe. Il n'y a aucune raison de faire plus d'une couche d'AES-256 à moins que vous n'ayez un modèle de menace pour le sauvegarder.

Maintenant, pourquoi pensez-vous que la division du fichier aidera tu? Vous utilisez déjà certains des outils de cryptage les plus puissants de la planète. Pourquoi retenir une section serait-il vraiment utile? Bien sûr, si vous êtes confronté à un attaquant qui connaît une fissure actuellement non divulguée d'AES-256 mais ne sait pas comment procéder à l'ingénierie inverse d'un format de fichier divisé 7zip, cela pourrait aider. Ainsi pourrait-on du papier d'aluminium.

Je ne dirais pas que vous avez un théâtre de sécurité. La première étape est bonne: stocker les données dans un format crypté avec un bon mot de passe fort. Le reste du processus, cependant, est le théâtre de la sécurité. Ne perdez pas votre temps à mettre des couches sur des couches de chiffrement.

Le pire des cas est que vos efforts trop zélés vous empêchent d'accéder aux données car vous avez rendu 10 fois plus difficile l'accès à vos propres données. La probabilité d'erreurs dans le processus qui rendent vos données inaccessibles est grande, et vous n'avez obtenu aucune sécurité réelle appréciable pour cela.

@Nat La partie la plus délicate est de trouver des techniques qui seraient réellement sûres dans 50 ans.Si votre modèle de menace comprend 50 ans de progression dans le matériel informatique et les connaissances cryptographiques, vous voyez assez rapidement qu'il y a de très bonnes chances que vos sept couches de cryptage aient augmenté le temps de déchiffrement de 2 secondes à 14 secondes.Il est un peu plus difficile d'augmenter le temps à 2 ^ 7 secondes.Il peut être intéressant de noter que si un grand gouvernement veut garder quelque chose secret pendant 50 ans, il le stocke dans un coffre-fort et met des gardes à la porte.
@Nat C'est pourquoi je dis simplement faire 1 couche d'AES.** S'il n'y a ** aucune nouvelle attaque cryptographique contre AES au cours des 50 prochaines années, alors l'AES en couches augmentera la complexité de manière exponentielle.Cette garantie échoue s'il y a des attaques cryptographiques (qui, si l'historique est un indicateur, il y en aura).Il échoue également, par exemple, si vous faites ce que fait l'OP, en utilisant plusieurs couches de fichiers 7zip protégés par mot de passe, qui ne seront pas exponentiels.Vous devez vraiment le faire correctement, ou pas du tout.
Et, à un moment donné, vous devez admettre que lorsque le cryptage que vous cherchez à appliquer à vos données est supérieur à ce que le gouvernement américain applique lors du cryptage de ses informations top secret / SCI pour la transmission sur Internet, vous ne devriez probablement pas stockerles données dans Dropbox.
+1 pour le dernier paragraphe.Le cryptage est bon lorsque vous voulez que vos données soient accessibles à (1) vous et (2) personne d'autre.Quand vous ne vous souciez que de (2), `rm (1)` est bien meilleur que AES.
Andrew
2017-03-24 18:33:04 UTC
view on stackexchange narkive permalink

Je ne suis pas aussi familier avec 7-Zip pour bien comprendre ses capacités. Cependant, en supposant qu'il ne s'agisse que d'un fichier zip protégé par mot de passe, alors non, ce n'est pas sécurisé. Cependant, je vois quelques commentaires où 7-Zip peut offrir un cryptage basé sur AES qui serait sécurisé (en supposant qu'aucun bogue n'existe avec l'implémentation de 7-Zip, il a donc créé un fichier crypté AES vrai et valide).

En bref, tout ce qui peut être téléchargé et craqué hors ligne doit être supposé qu'il peut être craqué avec suffisamment de temps. En supposant que votre fichier 7-Zip est chiffré avec AES-256 (encore une fois, pas de bogue), vous seriez à la merci de l'entropie de vos mots de passe et de la vitesse de la machine de l'attaquant.

Au lieu de créer 5 ou 6 niveaux d'archives fractionnées, en utilisant une seule archive de mot de passe à haute entropie serait suffisant. Le fractionnement de l'archive ne fait rien car il suffit de pouvoir `` déverrouiller '' le premier pour pouvoir décrypter la chaîne d'archives.

En fin de compte, la réponse à votre question est qu'il suffit simplement de l'utiliser 7-Zip avec AES-128 ou 256 tant que vous utilisez un mot de passe vraiment aléatoire et sécurisé avec autant d'entropie que possible. 64 caractères en majuscules, minuscules, nombres et symboles sans motifs ni répétitions discernables sont parfaitement acceptables. N'écrivez pas le mot de passe sur une note autocollante et laissez-le sur votre moniteur. Utilisez un véritable gestionnaire de mots de passe pour garder une trace de ce mot de passe de 64 caractères et assurez-vous d'utiliser un bon mot de passe principal sécurisé sur ce gestionnaire de mots de passe. Vous êtes aussi sûr que la méthode la moins sécurisée - coller votre mot de passe sous forme de fichier texte brut sur votre bureau n'est pas sécurisé.

Gardez à l'esprit également qu'il peut être plus facile en tant que accédez simplement à votre PC pour capturer ces mêmes données - gardez à l'esprit de qui vous essayez de vous protéger. Dans ce cas, ce qui précède est parfaitement acceptable pour quelque chose comme Google Drive / Dropbox et craint qu'ils ne soient exposés (ou des employés curieux).

Paul
2017-03-25 04:31:24 UTC
view on stackexchange narkive permalink

Toutes les réponses données jusqu'à présent sont excellentes! Cependant, je pense qu'il reste une possibilité à mentionner. J'ai remarqué dans la question initiale que l'OP mentionnait la longueur du mot de passe (mots de passe à 32 caractères) et plaçant un élément sur un deuxième service cloud qui serait nécessaire pour décrypter les données d'origine.

Je crois que VeraCrypt prend en charge les fichiers de clés et cela répondrait à deux ou trois choses dans la question d'origine.

  • Augmenter la difficulté de la force brute (en supposant que l'attaquant n'a pas de fichier de clés ou de mot de passe)
  • Autoriser le fichier de clés à être stocké dans un emplacement distinct (2ème service cloud) des données chiffrées.
  • Moins de bande passante car vous n'avez pas à transférer les données réelles vers le 2ème service cloud. (sauf si vous le souhaitez)
  • Limitation: il ne serait pas utile de trouver une vulnérabilité AES sans force brute qui ne nécessite pas la clé / mot de passe pour déchiffrer.
daniel
2017-03-24 18:51:19 UTC
view on stackexchange narkive permalink

C'est bien. Certaines parties sont probablement redondantes (en utilisant le même système de cryptage plus d'une fois), mais si vous aviez à la place le premier zip et que vous ajoutiez ensuite des données brutes, puis mettez tout cela dans un zip et ainsi de suite, cela aurait du sens, alors c'est comme passez le colis avec vos fichiers les plus anciens au milieu.

Ensuite, pour l'étape où vous retirez un morceau pour le rendre illisible, c'est possible mais pas aussi simple que vous le dites. Vous devrez utiliser une implémentation du partage secret de Shamir, ou XOR le fichier codé compressé final avec des données aléatoires, puis enregistrer le résultat en ligne et les données aléatoires ailleurs.

Je ne reçois pas le vote négatif, Neli a demandé si 7zip est sécurisé, ce qui est le cas si l'AES-256 est correctement implémenté.Bien sûr, le faire plusieurs fois n'augmente pas cette sécurité mais ne l'empire pas.De plus, même la méthode de fractionnement de fichiers qu'il a proposée ajoute une certaine protection, si quelqu'un dit "J'ai compressé un film et l'ai divisé en 10 parties, en voici 9, dites-moi ce qui se passe dans le film", je vous dirais que j'ai besoinl'aide du 10e bit ou NSA.
Je ne suis pas celui qui a voté contre, mais vous le dites vous-même "le faire plusieurs fois n'augmente pas cette sécurité mais ne l'empire pas".Elle n'augmente pas la sécurité, elle n'est donc pas plus sûre que toute autre méthode.Ce que OP essaie de faire, c'est d'augmenter la sécurité, ce qui ne se produit pas par ce processus.
Il semble penser que le faire 5 fois le rend automatiquement 5 fois plus sûr, ce qui n'est peut-être pas vrai (ce que Philipp a mis mieux que moi).Mais en fonction des choses, cela pourrait ajouter une certaine sécurité (comme si AES-256 était partiellement cassé, mais qu'il fallait 1 an pour le casser, alors son dossier prendrait 1 à 5 ans pour y arriver).Le cryptage d'empilement est effectué, mais cela signifie généralement empiler différents algorithmes pour une bonne raison.
La mise en place d'un cryptage automatisé à plusieurs passes est une perte de temps pendant laquelle vous auriez pu faire quelque chose qui présente réellement un avantage en matière de sécurité, donc ce n'est pas bien: cela diminue votre sécurité par rapport à ce que vous pourriez réaliser avec la même quantité de ressources en suivant les meilleures pratiques.(Par exemple, empiler différentes méthodes de cryptage, comme vous le dites. Ce qui présente l'avantage supplémentaire que vous pouvez utiliser un logiciel de cryptage largement fiable comme l'un de vos laissez-passer, au lieu d'avoir à espérer que le logiciel 7z - pas vraiment axé sur la sécurité - implémente le cryptagecorrectement.)
Mais cela présente un avantage en matière de sécurité, personne ici qui n'a pas encore trouvé de fissure pour AES-256, ou une faille dans son implantation dans 7zip ne peut dire à quel point cet avantage est important.La chose qu'il devrait faire est de prendre la première des archives séparées (1 sur 10 ou autre) chaque fois qu'il crypte, et cela augmente vraiment la sécurité à un degré que personne ne peut calculer.Et comme je l'ai dit au début, si vous voulez que ce soit impossible, utilisez un pad unique.
ex-university-cyber-guy
2017-03-25 02:44:59 UTC
view on stackexchange narkive permalink

Votre méthode de fractionnement zip est absurde et n'ajoute aucune valeur de protection. Utilisez simplement une méthode de compression bien comprise, bien testée et fortement cryptée et vous serez suffisamment en sécurité pour répondre à vos besoins déclarés. Si vous ne pouvez pas faire confiance à la compression (Zip ou autre), séparez la compression des données du conteneur de chiffrement si cela vous permet de vous sentir mieux. Les multiples et divisions que vous décrivez ajoutent de la complexité sans ajouter de sécurité significative (comme la force des clés ou la vérification des processus). Vous ne résoudrez pas les implémentations défectueuses de compression + chiffrement en le faisant plusieurs fois.

Solomon Ucko
2017-03-25 17:54:03 UTC
view on stackexchange narkive permalink

En plus des autres réponses, je tenais à souligner que vous auriez à stocker les mots de passe quelque part. S'ils obtiennent les mots de passe, ils peuvent facilement accéder aux données. Si vous vouliez les sécuriser, vous devrez crypter les mots de passe, et stocker leurs mots de passe quelque part, etc.

cela est également couvert par d'autres réponses
Je n'ai rien vu, mais je l'écrémais juste.Dois-je le supprimer ou le conserver?


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...