• # bah euh

    Posté par  (site web personnel) . Évalué à 10.

    chiffrer ses mails après qu'ils aient transité en clair, est-ce vraiment utile ?

    Si tu ne veux pas qu'on puisse les lire, voit plutôt du coté des droits de la machine et d'un filesystem chiffré si t'as peur qu'on chroot ton disque pour les contourner

    Autrement, tu pourras facilement les chiffrer avec ta clé publique mais du coup je ne vois pas comment alors remplacer le mail non chiffré dans kmail par ta copie chiffrée.

    peux tu nous en dire plus sur la finalité de la manoeuvre ?

    • [^] # Re: bah euh

      Posté par  . Évalué à 2.

      bonnes remarques, c'est sans doute un peu idiot ce que je veux faire.
      En fait, j'ai déjà un système de fichier chiffré, et je suis sur un portable (mono utilisateur).

      Je souhaite faire des sauvegardes vers des serveurs et j'ai une confiance limitée dans ceux-ci. La plupart de mes fichiers pourraient y être stockés en clair, mais certains devront être chiffrés (comme quelques emails).

      • [^] # Re: bah euh

        Posté par  (site web personnel) . Évalué à 0.

        des sauvegardes chiffrées ne sont pas des sauvegardes (le serveur de sauvegarde aussi peut avoir un souci...). Une sauvegarde c'est facilement récupérable (par définition) et est dans un emplacement en lequel tu as une entière confiance (d'où le non besoin de chiffrer), le plus dur étant d'identifier quelle sauvegarde est la plus à jour.

        • [^] # Re: bah euh

          Posté par  . Évalué à 3.

          D'un autre côté à défaut d'un emplacement dans lequel on a une entière confiance (par exemple pour un particulier qui n'a pas des ressources infinies à consacrer à un lieu de stockage sécurisé), utiliser plusieurs services de stockage distant type amazon storage et concurrents sur lesquels on stocke une copie chiffrée des données à sauvegarder ramène le problème du stockage des données à celui du stockage d'une phrase de passe (utiliser par exemple openssl avec un chiffrement symétrique et une clef dérivée de la phrase de passe).

          Cette dernière est quand même bien plus simple à sauvegarder efficacement (ne serait-ce que dans la tête et une copie papier dans le portefeuille par exemple), et le contrôle d'accès aux données sensibles des sauvegardes est largement facilité.

          Niveau facilité enfin, on peut par exemple monter un répertoire amazon storage sur son système de fichier local via une couche de chiffrement, qui fait que seules des données chiffrées transitent sur le web.

          • [^] # Re: bah euh

            Posté par  . Évalué à 3.

            une copie papier dans le portefeuille

            Noooon pas çaaaaa
            On ne note jamais un mot de passe, encore moins une passphrase.

            Et on ne boit pas trop d'alcool, car on serait capable de dire un mot de passe une fois bourré.

            Un peu d'éthique, bon sang!

            THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

            • [^] # Re: bah euh

              Posté par  (site web personnel) . Évalué à 5.

              Mon détecteur à sarcasme ne sait pas trop comment réagir... Est-ce que tu suggères sérieusement que l'endroit où je stocke déjà ma carte bancaire, ma CNI et ma carte grise est un mauvais endroit pour stocker le mot de passe permettant de déchiffrer mes archives ?

              C'est pas moi qui le dis, c'est Schneier : <http://www.schneier.com/blog/archives/2005/06/write_down_you(...)

              • [^] # Re: bah euh

                Posté par  . Évalué à 2.

                bah si ca a pas une tete de mot de passe, cle ssh ou de passphrase, pourquoi pas ?

                un poeme, une carte de club avec un numero cabalistique dessus... ca passe inaperçu

      • [^] # Re: bah euh

        Posté par  (site web personnel) . Évalué à 2.

        Si tu veux quelque chose de facilement rsync'able, encfs avec son option reverse peut être une solution.

        encfs --reverse /mon/dossier/clair /mon/dossier/chiffré
        rsync /mon/dossier/chiffré ssh://serveurdistant/srv/backups

        De cette façon, tout est chiffré, tu n'as pas besoin d'avoir confiance en l'admin de la machine distante, etc. (enfin, si, il doit être possible pour lui de supprimer des dossiers ; mais pas d'en modifier ou d'en ajouter).

        Sinon, l'autre façon est d'utiliser gpg, quelque chose du genre (non testé) :

        tar -c -f - -C /home/PegaseYa Mails | gpg --encrypt --sign | ssh serveurdistant "cat - > /srv/backups/Mails.tar.gpg"

        (Signer + chiffrer, de cette façon l'admin de serveurdistant ne peut pas modifier tes backups à ton insu.)

        • [^] # Re: bah euh

          Posté par  . Évalué à 2.

          L'admin de serveurdistant peut échanger tes backups les uns avec les autres, et lorsque tu restaures, il te file un vieux backup, non?

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # Re: bah euh

            Posté par  (site web personnel) . Évalué à 2.

            C'est vrai, je n'avais pas pensé à cela. Mais les signatures faites par GPG sont signées, non ? Et au pire, tu peux garder en local une table de correspondance date du backup => SHA512 du backup, ou alors inclure dans chaque backup un fichier de méta-données avec en autres la date. Dans ce cas, c'est un peu moins simple que ce que je décrivais...

      • [^] # Re: bah euh

        Posté par  (site web personnel) . Évalué à 3.

        Utilise duplicity pour tes sauvegardes, hop! problème réglé :)

      • [^] # Re: bah euh

        Posté par  . Évalué à 1.

        Il y a http://www.tarsnap.com qui propose un service avec une emphase sur la crypto. En bonnus, les profits sont reversés au projet FreeBSD. À essayer (en tout cas l'utilisation à l'air hyper simple http://www.tarsnap.com/usage.html ).

Suivre le flux des commentaires

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