• # site officiel

    Posté par . Évalué à 1.

  • # script pour chiffrer des fichiers et dossiers

    Posté par (page perso) . Évalué à 3.

    Perso j'ai fait ça, c'est bien pratique. Si un expert en chiffrement passe par la pour regarder les options choisies (gpg2), se serait sympa ;p C'est codé avec les pieds, en vitesse, avec des fôtes et avec peu de tests d'erreurs mais ça marche :)

    # Paternity : G. HUSSON - Liberasys - 2015
    # cryptFile <in_file_uncrypted> <out_file_crypted>
    cryptFile() {
      if [ $# -ne 2 ]; then
        echo "cryptFile" '<in_file_uncrypted> <out_file_crypted>'
      else
      GPG_AGENT_INFO__=$GPG_AGENT_INFO
      DISPLAY__=$DISPLAY
      unset GPG_AGENT_INFO
      DISPLAY=""
        FILE_UNCRYPTED=$1
        FILE_CRYPTED=$2
        gpg2 --out $FILE_CRYPTED --cipher-algo twofish --symmetric $FILE_UNCRYPTED
        GPG_AGENT_INFO=$GPG_AGENT_INFO__
        DISPLAY=$DISPLAY__
      fi
      }
    
    # unCryptFile <in_file_crypted> <out_file_decrypted>
    unCryptFile () {
      if [ $# -ne 2 ]; then
        echo "uncryptFile" '<in_file_crypted> <out_file_decrypted>'
      else
      GPG_AGENT_INFO__=$GPG_AGENT_INFO
      DISPLAY__=$DISPLAY
      unset GPG_AGENT_INFO
      DISPLAY=""
        FILE_UNCRYPTED=$2
        FILE_CRYPTED=$1
        gpg2 --out $FILE_UNCRYPTED --cipher-algo twofish --decrypt $FILE_CRYPTED
        GPG_AGENT_INFO=$GPG_AGENT_INFO__
        DISPLAY=$DISPLAY__
      fi
      }
    
    # cryptDir <in_directory path>
    cryptDir() {
      if [ $# -ne 1 ]; then
        echo "cryptDir" '<in_directory path>'
      else
        DIR_UNCRYPTED=$1
        FILE_CRYPTED=./$(basename $1).crypted
        if [ ! -d $DIR_UNCRYPTED ]; then
          echo "directory not found"
        else
          TEMP_GZIP_FILE=tmpCryptDir.$(basename $(/bin/mktemp)).gz
          tar czf $TEMP_GZIP_FILE $DIR_UNCRYPTED
          cryptFile $TEMP_GZIP_FILE $FILE_CRYPTED
          rm $TEMP_GZIP_FILE
        fi
      fi
      }
    
    # unCryptDir <in_file_crypted>
    unCryptDir() {
      if [ $# -ne 1 ]; then
        echo "unCryptDir" '<in_file_crypted>'
      else
        DIR_UNCRYPTED="./"
        FILE_CRYPTED=$1
        if [ ! -f $FILE_CRYPTED ]; then
          echo "file not found"
        else
          TEMP_FILE=`/bin/mktemp`
          TEMP_GZIP_FILE=tmpCryptDir.$(basename $(/bin/mktemp)).gz
          unCryptFile $FILE_CRYPTED $TEMP_GZIP_FILE
          tar xfzp $TEMP_GZIP_FILE
          rm $TEMP_GZIP_FILE
        fi
      fi
      }
    • [^] # Re: script pour chiffrer des fichiers et dossiers

      Posté par (page perso) . Évalué à 4.

      Bah perso je m'emmerde pas et j'utilise ccrypt. Juste deux petites actions personnalisées dans Thunar pour que ça soit accessible via clic-droit et hop ça roule:

      nom de l'action : chiffrer
      xfce4-terminal --working-directory=%f -x ccrypt -e %f

      nom de l'action : déchiffrer
      xfce4-terminal --working-directory=%f -x ccrypt -d %f

      • [^] # Re: script pour chiffrer des fichiers et dossiers

        Posté par (page perso) . Évalué à 2.

        Je voulais utiliser un algo de chiffrement qui ne soit pas "trop" utilisé.
        CCRYPT utilise l'algo Rijndael, choisi pour le standard AES. En bon parano, ça ne me plaît pas.
        J'ai préféré utiliser twofish.
        Mais ta solution semble simple et efficace, j'aime bien ;)

        • [^] # Re: script pour chiffrer des fichiers et dossiers

          Posté par . Évalué à 5.

          Un algorithme "trop" utilisé est une bonne chose, il est inspecté par tout les chercheurs, professeurs et amateurs vu que c'est l'algorithme "de référence". Donc il a plus de chance d'être sécurisé si rien n'a été trouvé à ce jour.

          Et de plus, je ne suis pas cryptographe, mais expert en sécurité. Si tu lis les attaques sur Twofish et Rijndael, rien n'a été trouvé sur Rijndael, mais Twofish a deux attaques théoriques à son actif.

          Qui plus est AES a été approuvé par le NIST, CRYPTREC et NESSIE qui sont trois panels de cryptographes respectivement américan, japonnais et européen. Alors que Twofish ne s'est retrouvé que finaliste de la competition du NIST.

          Ajoute à ça le fait fait que Rijndael est recommandé par Colin Perceval (cryptographe reconnu et compétent) dans Cryptographic Right Answers alors que Twofish n'est ni mentionné dans la billet de Colin, ni dans la mise à jour de "Cryptographic Right Answers".

          Donc ton choix de Blowfish me parait plus relever de la pseudo-science.

          Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »

          • [^] # Re: script pour chiffrer des fichiers et dossiers

            Posté par (page perso) . Évalué à 4.

            Si tu lis les attaques sur Twofish et Rijndael, rien n'a été trouvé sur Rijndael, mais Twofish a deux attaques théoriques à son actif.

            Euh, si, des attaques théoriques sur Rijndael, il y en a. Juste quelques-unes :

            (Et juste pour le fun, la prétendue « attaque » de Filiol (2003), qui affirmait pouvoir casser non seulement AES mais n’importe quel algorithme de chiffrement par blocs — étonnamment (ou pas), personne n’a pu reproduire ses résultats.)

            En fait, il y a probablement plus d’attaques (encore une fois, théoriques) sur Rijndael que sur n’importe quel autre finaliste de la compétition AES. L’intérêt des cryptologues pour les autres algorithmes s’est éteint lorsque Rijndael a été sélectionné (pourquoi s’attaquer à des algorithmes que personne ne va utiliser puisque tout le monde choisit l’algorithme standard ?).

            Et ce sont justement toutes les attaques sur Rijndael qui renforcent la confiance dans cet algorithme : il est attaqué de toute part depuis quinze ans, et personne ne réussit à faire mieux que des attaques purement théoriques.

            Ajoute à ça le fait fait que Rijndael est recommandé

            Évidemment qu’il est recommandé, c’est devenu LE standard du chiffrement symétrique.

            En fait, AES est devenu l’algorithme que personne ne te reprochera de choisir, parce que tout le monde fait pareil. Si un jour il est cassé, le blâme ira à ses concepteurs. Alors que si tu utilises (au hasard) Twofish, et qu’il est un jour cassé, c’est toi qu’on blâmera pour avoir choisi autre chose que le standard.

          • [^] # Re: script pour chiffrer des fichiers et dossiers

            Posté par (page perso) . Évalué à 1. Dernière modification le 17/01/16 à 00:11.

            Je comprend tout à fait ton point de vue. De mon côté j'ai été ingé sécu pendant 1 an mais je n'ai jamais passé le temps nécessaire à étudier les algos de chiffrement plus en détail que les concepts généraux (symétrique, asymétrique, hash - ou je sais ce n'est pas du chiffrement :). La c'est pour moi une bonne occasion d'en discuter.

            Tout d'abord, j'aimerais comprendre ce que c'est une attaque théorique ? Ça peut pas être mise en pratique facilement ? Ça a jamais été utilisé ? Apparemment ça ne suffit pas à remettre en cause un algo ? Si tu as une doc sur le sujet je suis preneur.

            Ensuite pour expliquer ma position AES/twofish :
            - AES choisi fin 2000 par le NIST et approuvé par la NSA
            - en france : en 2004, plus de limitation légale de la taille des clefs
            - 2008 j'achète une WII, je sniffe un peu et ohhhh… l'échange des certificat ne se fait pas selon un standard mais sur un algo asymétrique basé sur les courbes elliptiques
            Conclusion dans ma tête :
            1) les états on un moyen de déchiffrer simplement (ou au moins plutôt rapidement) les algos posés en standard
            2) les industriels passent sur des algos autres
            Corollaire : pour choisir un algo, prends en un pas cassé et qui ne soit pas un standard (posé en tant que, ou de fait).
            Ce n'est que mon point de vue et je n'ai pas tes connaissances. J'aimerais bien que tu donnes ton avis dessus STP ?

            • [^] # Re: script pour chiffrer des fichiers et dossiers

              Posté par (page perso) . Évalué à 0.

              Et autre argument en passant :
              Quand j'ai vu il y a 2 ans sur ebay des clusters de GPU ou de FPGA pour casser du bitcoin (dont le chiffrement -asymétrique- est lui aussi basé sur sur un algo à courbes elliptiques), je me suis dit qu'il était temps de passer sur les algos qui sortaient des sentiers battus dont les outils de brute force ou presque (j'entends par presque : présentant des optimisation algorithmiques pour le déchiffrement) avaient moins de chance d'exister ou d'être connus.
              Et en passant, les processeur ARM avec FPGA intégrés, ils vont servir à quoi aux services de renseignement à votre avis ? ;p

            • [^] # Re: script pour chiffrer des fichiers et dossiers

              Posté par (page perso) . Évalué à 5.

              Tout d'abord, j'aimerais comprendre ce que c'est une attaque théorique ?

              Une attaque qui n’est pas réalisable en pratique, pour plusieurs raisons possibles :

              • parce qu’elle ne concerne qu’une version « castrée » de l’algorithme et n’est pas transposable à la version complète (par exemple, une attaque contre une version d’AES128 réduite à 6 tours, alors que la version complète comprend 10 tours) ;
              • parce qu’elle ne réduit la complexité que très marginalement par rapport à une attaque par recherche exhaustive de la clef, restant ainsi complètement hors de portée d’une application pratique ;
              • parce qu’elle nécessite d’énormes quantités de textes chiffrés avec la même clef que celle que l’on cherche à casser ;
              • etc.

              Mais pour les cryptologues, toute attaque qui est moins complexe que la recherche exhaustive (aka brute-force) est formellement une attaque réussie, même si elle est complètement irréalisable.

              Par exemple, l’attaque de Bogdanov et al. (2011) contre AES128 nécessite 288 paires de textes chiffrés/textes clairs et environ 2126 opérations pour retrouver une clef. Irréalisable, mais il n’empêche : elle est moins complexe qu’une recherche exhaustive de la clef (qui demanderait en moyenne 2127 opérations), donc c’est une bonne attaque.

              Apparemment ça ne suffit pas à remettre en cause un algo ?

              Non.

              • 2008 j'achète une WII, je sniffe un peu et ohhhh… l'échange des certificat ne se fait pas selon un standard mais sur un algo asymétrique basé sur les courbes elliptiques […] les industriels passent sur des algos autres

              Je ne sais pas ce qu’utilise la Wii, mais es-tu bien sûr que son algo asymétrique n’est pas standard ? Les industriels n’ont pas sorti les algorithmes à bases de courbes elliptiques d’un chapeau, hein. La plupart des implémentations utilisent les courbes standardisées par le NIST (NIST P256, P384, P521).

              • [^] # Re: script pour chiffrer des fichiers et dossiers

                Posté par (page perso) . Évalué à 1.

                Tout d'abord merci beaucoup pour cette explication. J'y vois plus clair.

                Concernant la WII : quand je dis standard c'est plutôt standard d'utilisation (cad utilisé majoritairement). Ce n'est pas (encore) le cas des algos basés sur les courbes. Je n'ai pas retrouvé d'info concernant le processus d'authentification du serveur, mais j'ai trouvé ça : http://www.games.slashdot.org/story/07/09/16/0317204/wii-uses-elliptic-curve-cryptography-for-saves

                Pour info sur le sujet j'ai trouvé ça qui pourrait t'intéresser : http://www.nist.gov/itl/csd/ct/ecc-workshop.cfm

                • [^] # Re: script pour chiffrer des fichiers et dossiers

                  Posté par (page perso) . Évalué à 4.

                  quand je dis standard c'est plutôt standard d'utilisation (cad utilisé majoritairement). Ce n'est pas (encore) le cas des algos basés sur les courbes

                  Oui et non.

                  Dans TLS par exemple, si la cryptographie ECC est encore rarement utilisé pour l’étape d’authentification (seuls 4% des certificats des serveurs web utilisent une clef ECDSA d’après l’université de Berkeley, contre 96% qui ont une clef RSA), elle est beaucoup plus fréquente lors de l’étape d’échange de clef (environ 75% des connexions utilisent un échange Diffie-Hellman sur courbe elliptique, d’après la même étude).

                  Et puisqu’on parlait de consoles, ECDSA a aussi notoirement été utilisé par dans la PlayStation 3 — un fait « notoire » principalement parce que Sony a magistralement foiré l’implémentation de l’algorithme… illustrant au passage deux points :

                  • il est toujours plus facile de trouver une faille dans l’implémentation d’une primitive cryptographique, ou dans tout le code qui gravite autour, que d’attaquer la primitive proprement dite (Cryptography is bypassed, not penetrated — Adi Shamir) ;

                  • corollairement, la rigueur accordée à l’implémentation compte beaucoup plus que le choix de l’algorithme (entre AES ou Twofish, c’est kif-kif bourricot, mais mieux vaut encore un 3DES codé avec soin qu’un AES codé avec les pieds).

                  • [^] # Re: script pour chiffrer des fichiers et dossiers

                    Posté par (page perso) . Évalué à 1.

                    Eh bien merci pour les stats, ça me surprend.
                    Et je suis bien d'accord avec tes deux points de conclusion. Et au delà de ça, les attaques par canaux auxiliaires c'est tellement bon ;p
                    Merci pour cet échange constructif, j'ai appris des choses et j'y vois un peu plus clair :)

    • [^] # Re: script pour chiffrer des fichiers et dossiers

      Posté par (page perso) . Évalué à 5.

      Je ne suis pas sûr de comprendre pourquoi tu unset GPG_AGENT_INFO, mais quelle qu’en soit la raison, attention : cette variable n’a plus aucun effet à partir de GnuPG ≥ 2.1. À partir de cette version, la socket de l’agent GPG n’est plus variable, mais toujours située à l’emplacement $GNUPG_HOME/S.gpg-agent.

      Si le but était de forcer GnuPG à démarrer un nouvel agent sans utiliser celui déjà lancé (pourquoi ?)… ça ne marchera pas avec GnuPG ≥ 2.1.

      • [^] # Re: script pour chiffrer des fichiers et dossiers

        Posté par (page perso) . Évalué à 1.

        La raison je ne la connais plus. Si j'ai fait ça c'est qu'il y a avait quelque chose qui me cassait les noix… Peut être la demande de mot de passe en interface graphique ou une interaction avec le profil utilisateur ?

    • [^] # Re: script pour chiffrer des fichiers et dossiers

      Posté par . Évalué à 4.

            TEMP_GZIP_FILE=tmpCryptDir.$(basename $(/bin/mktemp)).gz
            unCryptFile $FILE_CRYPTED $TEMP_GZIP_FILE
            tar xfzp $TEMP_GZIP_FILE
            rm $TEMP_GZIP_FILE

      Je ne suis pas un expert, mais j'utilise un truc approchant pour mon carnet de mots de passes : il faut faire attention à toujours décompresser dans un tmpfs, autrement il est en théorie possible de retrouver par la suite tout ou partie de tes données en clair en analysant ton disque. Tu y as peut-être pensé, mais mieux vaut le préciser.

    • [^] # Re: script pour chiffrer des fichiers et dossiers

      Posté par . Évalué à 2.

      Ce code m'a l'air bien plus compliqué qu'il ne devrait l'être. Il utilise une myriade de fichiers temporaires qui ne sont pas bien nettoyés à la fin. Pourquoi ne pas utiliser des pipes? c'est tout l’intérêt.

      Ce code devrait être quelque chose comme ça (j'écris ça de tête):

      #!/usr/bin/env bash
      
      set -e
      
      if [ "$#" -eq 0 ] 
      then
        echo "usage: $0 <directory> [output]" > /dev/stderr
        exit 2
      fi
      
      tar -c "$1" | gpg --symetric --armor > "${2:-/dev/stdout}"

      Ruby est le résultat d'un gamin qui apprend le Java, puis jette un œil à Perl et se dit « je peux le réparer! »

      • [^] # Re: script pour chiffrer des fichiers et dossiers

        Posté par (page perso) . Évalué à 1.

        Des myriades des fichiers temporaires non. Des myriades de variables temporaires oui ;p
        J'avais préviendu que c'était codé avec les pieds :-)
        Merci pour ton exemple plus efficace.

      • [^] # Re: script pour chiffrer des fichiers et dossiers

        Posté par (page perso) . Évalué à 5.

        Pourquoi ne pas utiliser des pipes? c'est tout l’intérêt.

        Pour le chiffrement, OK, mais pour le déchiffrement, c’est à éviter.

        Pour des raisons historiques, OpenPGP (et donc GnuPG) fonctionne en mode MAC-then-Encrypt. Un MAC est calculé sur le texte clair, ajouté à la fin du texte (RFC 4880, §5.13), et l’ensemble est ensuite chiffré. (C’est une mauvaise stratégie et ça fait partie des choses que le prochain RFC sur OpenPGP devrait corriger.) Ce n’est donc qu’après avoir déchiffré tout le texte chiffré que GnuPG peut enfin prendre connaissance du MAC et ainsi vérifier l’intégrité du texte clair.

        Si tu fais quelque chose comme ça :

        gpg -d archive.tar.gpg | tar xf -
        

        tu envoies à tar un texte clair dont l’intégrité n’a pas (encore) été vérifié. Si l’archive chiffrée a été modifiée par un attaquant, GnuPG affichera un message d’erreur en fin d’opération, mais dans le contexte d’un script appelé depuis une interface graphique (sans console pour afficher la sortie d’erreur standard), celui-ci passera inaperçu.

        Il faut laisser GnuPG déchiffrer intégralement le fichier, vérifier le code de retour, et ensuite seulement détarrer l’archive :

        if gpg -o archive.tar -d archive.tar.gpg ; then
            # OK, on peut continuer
            tar xf archive.tar
        else
            # Il y a quelque chose qui ne va pas
            # Même si GnuPG a commencé à écrire le
            # fichier archive.tar, on ne peut pas s’y fier!
            # Prévenir l'utilisateur ou faire autre chose
            :
        fi
        
        • [^] # Re: script pour chiffrer des fichiers et dossiers

          Posté par (page perso) . Évalué à 3.

          Je ne comprends pas pourquoi il ne faut pas utilisé les pipes. Quelle est la différence entre ce que tu propose et

          gpg -d archive.tar.gpg | tar xf -
          if [ ${PIPESTATUS[0]} -eq 0 ] ; then
              echo success
          else
              echo ko
          fi

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: script pour chiffrer des fichiers et dossiers

            Posté par (page perso) . Évalué à 5.

            Avec ta méthode, tu es informé du problème rencontré par gpg, mais ça ne change rien au fait que tu as déjà envoyé à tar une archive non-vérifiée, tu n’es informé de l’erreur qu’a posteriori. Charge ensuite à toi, en cas d’erreur, d’aller défaire tout ce que tar a fait (en espérant qu’il n’ait pas déjà écrasé des fichiers pré-existants).

            Il est plus sûr d’attendre que GnuPG ait fini son travail (y compris la vérification d’intégrité) avant de faire quoi que ce soit avec le texte déchiffré.

            • [^] # Re: script pour chiffrer des fichiers et dossiers

              Posté par . Évalué à 2.

              Ce que tu dis est effectivement très bon à savoir quand on récupère un fichier tiers, mais dans le cas présent le but du chiffrement est de rendre inaccessibles les données locales par quelqu'un d'autre que soi-même. Si l'attaquant a pu pourrir le fichier (dont les données n'existent nulle-part sur le disque, sinon ça ne sert à rien), c'est qu'en amont le système est très compromis (l'attaquant peut de toute manière supprimer/modifier a minima tous les fichiers de l'utilisateur).

              À moins que tu te ne places dans la perspective où on va récupérer une sauvegarde distante, mais ce ne sera pas le cas le plus fréquent, si bien qu'on peut associer la vérification préalable d'intégrité à son seul rapatriement.

            • [^] # Re: script pour chiffrer des fichiers et dossiers

              Posté par (page perso) . Évalué à 4.

              Je ne l'ai pas mis pour l'exemple en question mais tu peux détaré dans un dossier temporaire, ça permet d'ailleurs de vérifier qu'il n'y a pas d'erreur pour ça non plus.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: script pour chiffrer des fichiers et dossiers

                Posté par (page perso) . Évalué à 5.

                tu peux détaré dans un dossier temporaire

                C’est une protection suffisante, seulement si la version de tar utilisée prend soin de ne jamais rien écrire ailleurs que dans le répertoire courant (en supprimant le '/' initial des noms de fichiers dans l’archive et en refusant d’extraire les fichiers dont le nom comprend des '..'). C’est ce que fait GNU tar par défaut (sauf si l’option --absolute-paths est utilisée), mais ce n’est pas forcément le comportement des autres versions.

                • [^] # Re: script pour chiffrer des fichiers et dossiers

                  Posté par (page perso) . Évalué à 2.

                  Bon j'ai envie de dire : merci pour ces suggestions et merci de partager vos connaissances.
                  Si quelqu’un passe par la et a envie de mettre une version améliorée sur github, ça pourrait être bien ?
                  Ceci dit le seul avantage par rapport à la solution de patrick_g (ccrypt) c'est de pouvoir choisir des options sur l'algorithme utilisé.

                  • [^] # Re: script pour chiffrer des fichiers et dossiers

                    Posté par . Évalué à 2.

                    Je me joins à ghusson pour vous remercier pour vos contributions à ces discussions.
                    Sans avoir pour autant le niveau pour y participer, j'ai néanmoins beaucoup appris à vous lire.

                    Au plaisir.

    • [^] # Re: script pour chiffrer des fichiers et dossiers

      Posté par (page perso) . Évalué à 1.

      (en passant : désolé de faire diverger le sujet d'origine…)

  • # C'est quoi gnuPT ?

    Posté par . Évalué à 4. Dernière modification le 17/01/16 à 14:43.

    un pet libre ?

    Comment dans ce cas récupère-t-on les sources ?
    ```

    (désolé, pas pu le retenir celui-là ...)
    

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.