Journal un vrai coffre fort numérique

Posté par  . Licence CC By‑SA.
Étiquettes :
46
31
août
2016

En tant que fidèle lecteur de DLFP, euh, je voulais dire Linuxfr, je me disais qu'il serai enfin temps de contribuer un petit peu.

L'actualité mouvementée de ces derniers mois (et non je ne parle pas d'une tenue de plage controversée) m'a donné un sujet fort intéressant : le chiffrement !

Et non, ce ne sera pas un billet sur le risque ou l'avantage de chiffrer ses données, mais une petite astuce bien pratique pour qui veut garder certaines informations secrètes et bien gardées : la création d'un véritable coffre fort numérique.

Bien sur il faut qu'il soit bien caché, donc pas simple à trouver, dur à ouvrir pour d'éventuels indésirables indiscrets et simple d'utilisation.
au programme donc : création de disque dur virtuel et chiffrement et déguisement.

tout d'abord installer cryptsetup :

sudo apt-get install cryptsetup

ensuite on veut créer un fichier qui nous servira de disque dur, pour cela on utilise l'utilitaire dd qui nous permet de créer un fichier block par block avec le périphérique /dev/zero qui produit des bits à "0" en indiquant à la commande que l'on veut des blocs de 4 mégaoctet (bs=4M).

Créer son disque virtuel

Il convient de bien choisir sa taille : suffisamment grande pour stocker nos données mais pas trop pour rester discret et être transportable pour l'exemple on créera un disque de 2.1Go pour cela on fera 512 création de block de 4Mo.

dd if=/dev/zero of=disque-secret.img bs=4M count=512
on obtient ainsi un fichier de 2.1Go (illisible pour l'instant car il ne contient que des octets de valeur 0)
Pour pouvoir travailler sur ce fichier (qui au final a les mêmes caractéristiques qu'un disque dur), il va falloir en faire un périphérique (ici loop0), pour cela la commande losetup va être bien utile:

sudo losetup /dev/loop0 disque-secret.img
Formater et chiffrer le tout

il va falloir "formater" ce fichier, et comme on veut aussi le chiffrer on va utiliser cryptsetup et sa commande luksFormat, puis mk2fs.ext4 pour créer le système de fichier (en ext4):

sudo cryptsetup --verbose --verify-passphrase luksFormat /dev/loop0
il faudra ensuite rentrer une passphrase robuste… qui servira à chiffrer/déchiffer le volume afin qu'il ne soit pas décryptable par des yeux indiscrets…

sudo mkfs.ext4 -j /dev/mapper/disque-secret.img
Utilisation :

ensuite il ne reste plus quàa déchiffrer et monter le disque pour l'utiliser (ici dans tmp):

mkdir tmp && sudo mount /dev/mapper/disque-secret.img tmp
et pour refermer le tout :

    sudo umount tmp && sudo cryptsetup luksClose disque-secret.img

et supprimer le périphérique /dev/loop0

sudo losetup -d /dev/loop0
** Pour vivre heureux vivez caché **

pour bien cacher ce fichier (disque-secret.img) il suffit de changer son nom et son extension et le mettre dans un répertoire inattendu : par exemple bieber-song.mp3 ou video.ogg ou catalogue.pdf ou programe-systeme.bin : votre imagination fera le reste (soyez logique par rapport à la taille du fichier et choisissez un fichier que l'on a en général pas envie d'ouvrir…)

bien sur pour réouvrir l'ensemble :
1 / on crée /dev/loop0 avec losetup (sudo losetup /dev/loop0 bieber-song.mp3)
2 / on le déchiffre avec cryptsetup (sudo cryptsetup luksOpen /dev/loop0 bieber-song.mp3)
3/ on le monte sudo mount /dev/mapper/bieber-song.mp3 )
4/ quand on a fini on démonte le fichier et on re-chiffre (dans nautilus cela se fait en même temps)

vous voila avec un fichier anodin, transportable, chiffré dans lequel vous pouvez ranger en toute tranquillité vos mots de passes et autres fichiers sensibles.

nb: désolé pour l'affichage erratique : je me suis un peu battu avec les balises code^

  • # Wiki

    Posté par  . Évalué à 2.

    Vous pouvez contribuer à LinuxFR sur son wiki.

    • [^] # Re: Wiki

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

      Plutôt que d'écrire ce commentaire, le journal étant sous licence CC, ne serais-ce pas plus simple que tu copies/colles le texte dans le Wiki toi-même ???

    • [^] # Re: Wiki

      Posté par  . Évalué à 2.

      je n'y avais pas pensé, c'est vrai que pour ce sujet ça a du sens, n'hésite pas le faire (et éventuellement adapter la syntaxe de mes balises code …)

      • [^] # Re: Wiki

        Posté par  . Évalué à 2.

        Bon mis dans le wiki, mais ces balises code décidément je n'y arrive pas :/

        • [^] # Re: Wiki

          Posté par  . Évalué à 1.

          balises de code mises à jour, tu peux voir du coup que ce n'est pas compliqué.

  • # Image luks détectable

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

    Un scan complet du disque pourrait tomber sur l'image chiffrée Luks et en révéler la nature. Luks possède des en-têtes spécifiques détectables.

    Il vaudrait mieux chiffrer en omettant les en-têtes de sorte à ce que l'image chiffrée ne soit plus qu'un ensemble de bits aléatoires.

    • [^] # Re: Image luks détectable

      Posté par  . Évalué à 7.

      De toute façon, je pense que l'entropie du fichier devrait en trahir la vraie nature…

      • [^] # Re: Image luks détectable

        Posté par  (Mastodon) . Évalué à 7.

        Oh la bonne idée : créer un format encrypté qui contient des données inutiles, mais "réalistes". Ajouter de la stéganographie quoi.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Image luks détectable

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

          C'est la fonction de déni plausible (?), truecrypt proposait 2 conteneurs cryptés mais impossible de connaître la présence d'un 2ième sans avoir des sauvegardes plus anciennes pour voir quel bit ont été modifié.

          "La première sécurité est la liberté"

  • # Il manque une ligne

    Posté par  . Évalué à 4.

    sudo cryptsetup luksOpen /dev/loop0 disque-secret.img
    
  • # truncate à la place de dd

    Posté par  . Évalué à 9.

    Pour créer un fichier vide truncate me semble plus simple et lisible que dd.

    dd if=/dev/zero of=disque-secret.img bs=4M count=512
    

    Devient :
    truncate -S 2G disque-secret.img

    • [^] # Re: truncate à la place de dd

      Posté par  (Mastodon) . Évalué à 5.

      Simple, c'est évident. Clair… "truncate" tu te doutes pas trop qu'il va "créer" un fichier.

      Mais bon, je connaissais pas, je prends !

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: truncate à la place de dd

        Posté par  . Évalué à 4.

        "fallocate -l 2GB disque-secret.img" est plus parlant.

        • [^] # Re: truncate à la place de dd

          Posté par  . Évalué à 2.

          truncate a le mérite d'être dans coreutils, souvent plus présent.
          est-ce qu'il y a une différence entre les deux ?

      • [^] # Re: truncate à la place de dd

        Posté par  . Évalué à 2. Dernière modification le 06 septembre 2016 à 12:51.

        tu te doutes pas trop qu'il va "créer" un fichier

        un peu comme dd…
        toutes les commandes ne peuvent pas avoir un nom explicite.

        donc simple est peut être pas le terme.
        mais c'est bien plus rapide en tout cas.

  • # Détailler les commandes

    Posté par  . Évalué à 9.

    Le journal est déjà très bien, et je n'ai clairement pas la compétence pour en faire un de même acabit sur ce sujet. Toutefois, il m'a laissé un goût d'inachevé. En effet, je comprends le sens d'instructions comme dd if=XX of=YY, qui sont plutôt génériques sur les systèmes Linux voire Unix. Par contre, je ne comprends pas ce que fait cryptsetup, comment fonctionne la commande, quels sont les avantages et inconvénients de telle ouu telle option…

    Prenons un exemple :

    on va utiliser cryptsetup et sa commande luksFormat, puis mk2fs.ext4 pour créer le système de fichier (en ext4)

    Ici, tu expliques succinctement mais clairement ce que fait mkfs.ext4, c'est top. Par contre, cryptsetup et luksFormat restent à l'état de baguettes magiques qu'on utilise sans trop savoir comment, ni pourquoi. C'est très bien tant que notre cas d'utilisation correspond exactement à ce qui est décrit, mais si on en dévie, on peut se retrouver avec des erreurs de l'espace, sans savoir pourquoi. C'est dommage, parce quele journal est vraiment intéressant ;)

    Ça, ce sont les sources. Le mouton que tu veux est dedans.

    • [^] # Re: Détailler les commandes

      Posté par  . Évalué à 5.

      merci de ton commentaire et de tes remarques pertinentes, je tacherai d'etre plus explicite/complet dans mes prochains écrits.

      • [^] # Re: Détailler les commandes

        Posté par  . Évalué à 9. Dernière modification le 31 août 2016 à 16:09.

        En fait, tu pourrais passer ton journal en dépêche : comme ça, tu aurais l'occasion de revenir sur les modifications qui t'ont été proposées dans les commentaires, et tu aurais l'occasion d'être plus explicite, tout en profitant de la rédaction collaborative. Et ça nous changerait des sempiternelles dépêches sur les journées du Libre à Moirans-la-Galifette ou la sortie de tel ou tel logiciel libre que je n'utiliserai jamais ;)

        Ça, ce sont les sources. Le mouton que tu veux est dedans.

        • [^] # Re: Détailler les commandes

          Posté par  . Évalué à 2.

          bah j'ai cherché et je n'ai pas vu comment transformer ce journal en dépêche ! si quelqu'un veut bien m'expliquer (ou le faire) je suis partant pour compléter.

          • [^] # Re: Détailler les commandes

            Posté par  (Mastodon) . Évalué à 4. Dernière modification le 31 août 2016 à 18:02.

            Les modos font la "transformation". Mais tu devrais carrément en rédiger une nouvelle (en citant en lien ce journal comme point de départ).

            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Détailler les commandes

      Posté par  . Évalué à 3.

      Je te rejoints.
      Il serait par exemple intéressant d'expliquer le choix de l'option -j Create the filesystem with an ext3 journal.
      Ce qui fait, si je ne me trompe pas, la même chose que mkfs.ext3.

  • # Ma version

    Posté par  . Évalué à 10.

    Sans aucunement critiquer la méthode présentée dans le journal, je me permets de présenter ma propre solution.

    Elle est basée sur GnuPG (pour le chiffrement) et udisksctl (pour la manipulation de volumes, en gros la même chose que ce pour quoi est utilisé losetup dans le journal, mais sans avoir besoin de sudo).

    J’utilise GnuPG plutôt que cryptsetup pour pouvoir « ouvrir le coffre » avec ma carte OpenPGP.

    Sans fioritures, le code complet :

    #!/bin/bash
    # vault - Manages encrypted archives
    # Copyright (C) 2014,2015 Damien Goutte-Gattat
    # 
    # Copying and distribution of this file, with or without modification,
    # are permitted in any medium without royalty provided the copyright
    # notice and this notice are preserved.
    
    encrypted_vault_dir=${XDG_DATA_HOME:-$HOME/.local/share}/vaults
    decrypted_vault_dir=$XDG_RUNTIME_DIR/vaults
    default_size=8
    
    die()
    {
        echo "${0##*/}: $@" >&2
        exit
    }
    
    usage()
    {
        cat <<EOU
    Usage:
        [1] vault new <name> [size]
            Create a new vault with the specified name and size (in Mb).
            If size is not specified, default is ${default_size}Mb.
    
        [2] vault open <name>
            Open the specified vault.
    
        [3] vault close <name>
            Close the specified vault.
    
        [4] vault dclose [name]
            Close the specified vault without saving changes.
            If no vault is specified, all currently opened vaults
            are closed.
    
        [5] vault is-open [name]
            Return 0 if the specified vault is open, 1 otherwise.
    
        A default vault name may be specified in the DEFAULT_VAULT
        environment variable.
    EOU
    
        exit 0
    }
    
    open_vault()
    {
        local encrypted_vault=$encrypted_vault_dir/$1.gpg
        local decrypted_vault=$decrypted_vault_dir/$1.img
    
        [ -f $decrypted_vault ] && die "Vault $1 is already opened"
        [ -f $encrypted_vault ] || die "Cannot found vault $1"
    
        if ! gpg2 -o $decrypted_vault -d $encrypted_vault ; then
            rm -f $decrypted_vault
            die "Cannot decrypt vault $1"
        fi
        loop_device=$(udisksctl loop-setup --file $decrypted_vault | sed -nre 's,Mapped file .+ as (.+)\.,\1,p')
        udisksctl mount --block-device $loop_device --options fmask=0177
    }
    
    close_vault()
    {
        local encrypted_vault=$encrypted_vault_dir/$1.gpg
        local decrypted_vault=$decrypted_vault_dir/$1.img
    
        [ -f $decrypted_vault ] || die "Vault $1 is not opened"
    
        volume_name=$(echo $1 | tr a-z A-Z)
        loop_device=$(mount | grep /run/media/$USER/$volume_name | cut -d' ' -f1)
    
        udisksctl unmount --block-device $loop_device
        udisksctl loop-delete --block-device $loop_device
    
        if [ "x$2" = x1 ]; then
            gpg2 -o $encrypted_vault.$$ -e $decrypted_vault \
                && mv $encrypted_vault.$$ $encrypted_vault
        fi
        rm $decrypted_vault
    }
    
    close_all_vault()
    {
        ls $decrypted_vault_dir/*.img 2>/dev/null | while read vault ; do
            vault=${vault##*/}
            close_vault ${vault%.img} 0
        done
    }
    
    new_vault()
    {
        dd if=/dev/zero of=$1.img bs=1M count=$2
        /sbin/mkfs.vfat -n $(echo $1 | tr a-z A-Z) $1.img
        gpg2 -o $encrypted_vault_dir/$1.gpg -e $1.img
        rm $1.img
    }
    
    [ -d $encrypted_vault_dir ] || mkdir -p $encrypted_vault_dir
    [ -d $decrypted_vault_dir ] || mkdir -p $decrypted_vault_dir
    
    case "$1" in
    -h|--help|"")
        usage
        ;;
    
    -v|--version)
        sed -n '2,/^$/ s/^# //p' $0
        exit 0
        ;;
    
    new)
        [ -n "$2" ] || die "Missing vault name"
    
        new_vault $2 ${3:-$default_size}
        ;;
    
    open)
        vault=${2:-$DEFAULT_VAULT}
        [ -n "$vault" ] || die "Missing vault name"
    
        open_vault $vault
        ;;
    
    close)
        vault=${2:-$DEFAULT_VAULT}
        [ -n "$vault" ] || die "Missing vault name"
    
        close_vault $vault 1
        ;;
    
    dclose)
        vault=$2
        if [ -n "$vault" ]; then
            close_vault $vault 0
        else
            close_all_vault
        fi
        ;;
    
    is-open)
        vault=${2:-$DEFAULT_VAULT}
        [ -f $decrypted_vault_dir/$vault.img ] && exit 0 || exit 1
        ;;
    
    esac

    Petite subtilité supplémentaire permise par l’utilisation d’une carte OpenPGP : j’ai un script ~/.gnupg/scd-event appelé automatiquement par GnuPG à chaque « évènement » sur le lecteur de carte (insertion ou retrait de carte), avec le code suivant :

    #!/bin/bash
    
    card_status=$8
    
    case "$card_status" in
    NOCARD)
        vault dclose
        ;;
    esac

    qui me permet de refermer automatiquement le coffre simplement en retirant ma carte OpenPGP du lecteur.

    • [^] # Re: Ma version

      Posté par  . Évalué à 5.

      intéressant en effet, je ne connaissait pas, je vais approfondir (mais vais rester en ext4…), et effectivement l'usage d'un script simplifie le bouzin, c'est la suite logique, mon idée de base était de partager une astuce glanée il y a quelques années, et effectivement l'utilisation de luks est un choix de simplicité et pas de sécurité (cf le man, et cf surtout que je connais pas bien dm-crypt), je suis bien content d'avoir de nouveaux points de vue / conseils.

      note au passage, après réflexions, ce journal ne mérite pas de transformation en dépêches, apres tout un fil ça se lit^ le wiki en revanche sera complété au besoin :)

    • [^] # Re: Ma version

      Posté par  . Évalué à 3.

      Le fait de pouvoir utiliser un badge pour l'ouverture et le fait que l'on ait pas besoin de sudo sont très intéressants.

      Par contre, à la lecture de :

      open_vault()
      ...
          if ! gpg2 -o $decrypted_vault -d $encrypted_vault ; then
      ...
      
      
      close_vault()
      ...    rm $decrypted_vault

      Je comprends que les données déchiffrées sont présentes sur le disque dur et donc récupérables à chaud (débranchement sauvage) comme à froid (démontage par close_vault).

      Au moins un shred permettrait que les données ne soient pas récupérables à froid.

      Autre point, il me semble que udisksctl loop-delete ait besoin d'un accès root.

      • [^] # Re: Ma version

        Posté par  . Évalué à 2.

        Au moins un shred permettrait que les données ne soient pas récupérables à froid.

        Je ne suis pas vraiment convaincu de l’efficacité de shred (ou plus généralement du principe consistant à ré-écrire plusieurs fois « au même endroit » — avec toutes les couches qui s’intercalent entre le disque physique et le système de fichiers, peut-on être sûr que l’on ré-écrit bien « au même endroit » ?).

        Cela dit, si ça ne fait pas de bien, j’admets que ça ne peut probablement pas faire de mal d’ajouter un appel à shred à la fermeture.

        il me semble que udisksctl loop-delete ait besoin d'un accès root.

        Pas pour détruire un périphérique loop que tu as toi-même créé avec udisksctl loop-setup — du moins pas si Polkit est bien configuré.

        • [^] # Re: Ma version

          Posté par  . Évalué à 2.

          vec toutes les couches qui s’intercalent entre le disque physique et le système de fichiers, peut-on être sûr que l’on ré-écrit bien « au même endroit » ?

          Exactement. Le firmware du contrôleur SSD pour éviter de massacrer une cellule va mapper le block logique sur une nouvelle cellule. Après, je pense qu'un outil pour lire une cellule d'un SSD est plus compliqué qu'un extundelete ou diskrescue. Mais très certainement à la portée d'une agence gouvernementale.

          Cela plaide pour ne surtout pas déchiffrer l'image dans son entier et passer par un mapper en RAM.

  • # Moi aussi j’y vais de mon script.

    Posté par  . Évalué à 4. Dernière modification le 31 août 2016 à 20:05.

    J’avais posté ça il y a un mois environ :

    #!/usr/bin/env bash
    
    case "$1" in
    
        "open")
    
        sudo losetup /dev/loop5 ~/stash.img
        sudo cryptsetup luksOpen /dev/loop5 stash
        sudo mount /dev/mapper/stash ~/stash
        ;;
    
        "close")
    
        sudo umount ~/stash
        sudo cryptsetup luksClose /dev/mapper/stash
        sudo losetup -d /dev/loop5
        ;;
    
        "pass")
    
        $0 open;
        $EDITOR ~/stash/pass;
        $0 close;
        ;;
    
        *)
    
        echo "Usage: $0 [open|close|pass]"
        exit 1
        ;;
    
    esac

    Ça nécessite bien sûr de configurer sudo Lorsqu’il est monté, le volume est bien entendu visible par root et quiconque a les droits…

    Depuis j’y ai ajouté une vérification des sommes de contrôle des différents binaires, pour prévenir si l’un d’entre eux est modifié avant de déchiffrer le volume. Mais je l’ai pas sous la main là.

    Ça résume la méthode que tu as toi-même donné. J’ai ajouté la fonction "pass", parce qu’à la base je cherchais un gestionnaire de mot de passe du pauvre.

  • # Chipotage

    Posté par  . Évalué à 3.

    En voyant le titre j'ai pensé à autre chose. En effet coffre-fort numérique m'a fait pensé qu'un projet libre avait créé un coffre-fort numérique à valeur probatoire…

  • # Petite question, en parlant de ça...

    Posté par  . Évalué à 2.

    Effectivement, chiffrer, c'est un bon début. Mais bon, un mot de passe, ça se donne, de gré ou de force.
    Du coups, je me demandais : existe il une solution permettant pour un volume donné, par exemple, de le splitter en 2 et de déchiffrer la première partie si mot de passe 1, et la seconde si mot de passe 2 ? (ou une partition où tout l'espace ne serait pas réellement disponible mais sur lequel laisser tout de même quelques fichiers ?)

    • [^] # Re: Petite question, en parlant de ça...

      Posté par  . Évalué à 2.

      existe il une solution permettant pour un volume donné, par exemple, de le splitter en 2 et de déchiffrer la première partie si mot de passe 1, et la seconde si mot de passe 2 ?

      Quelle est la différence d’avec avoir deux volumes ?

      Si tu as un volume chiffré existant et que tu veux le spliter il faut créer deux nouveaux volumes puis copier les fichiers…

      • [^] # Re: Petite question, en parlant de ça...

        Posté par  (Mastodon) . Évalué à 5.

        L'idée c'est que sous la contrainte tu donnes le mot de passe numéro 1, qui déchiffre effectivement ton coffre-fort, la contrainte disparaît, tu as cédé, tout donné, mais il en manque en réalité une partie disponible uniquement si on a déchiffré avec le second mot de passe.
        Tu es propre de ton côté : tu as cédé, mais le type qui te contraignait n'a pas trouvé ce qu'il cherchait et en conclus que ce n'est pas là que ça se trouve.

        Donc tu as cédé, mais pas tout, pas le principal.
        Et a priori personne ne le sait, donc la contrainte ne devrait pas reprendre.

        Yth.

        • [^] # Re: Petite question, en parlant de ça...

          Posté par  . Évalué à 4.

          Le souci du déni plausible, c’est que ça ne marche que si ton adversaire n’en a jamais entendu parler…

          Or les programmes de chiffrement de volume qui offrent cette possibilité ne la cachent pas, bien au contraire (c’est largement expliqué dans la documentation de Veracrypt par exemple). Dès l’instant où ton adversaire se rend compte que tu utilises un programme permettant les volumes cachés, s’il n’est pas trop bête il soupçonnera que tu en as un (surtout si ① tu as lâché ton premier mot de passe un peu trop facilement et ② il ne trouve pas ce qu’il cherche dans le volume non-caché).

          Le pire, c’est que s’il n’est pas possible de démontrer la présence d’un volume caché, il n’est pas non plus possible de démontrer qu’il n’y en a pas. Du coup, celui qui n’utilise pas de volume caché risque de se retrouver face à un adversaire qui continuera à exiger le « second mot de passe » (qui n’existe pas, mais va donc persuader ton adversaire de ça).

          • [^] # Re: Petite question, en parlant de ça...

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

            De plus, comme dit plus haut luks possède des en-têtes spécifiques qui sont facilement identifiable.

            À vouloir jouer au plus malin sans savoir exactement ce qu'on fait, on risque juste d'aggraver son cas.

          • [^] # Re: Petite question, en parlant de ça...

            Posté par  . Évalué à 2.

            cette reflexion me fait fortement penser à "where is jessica hyde", et de l'acharnement de l'interrogateur… scene(s) culte de la série Utopia…

          • [^] # Re: Petite question, en parlant de ça...

            Posté par  (Mastodon) . Évalué à 2.

            Ah ben moi j'ai exposé la théorie hein…

            Après faut être plus malin : utiliser une techno qui ne permet pas de faire de double mot de passe (Luks ne le permet pas ?), et s'assurer de n'utiliser qu'une portion, au début, de la partition cryptée.
            Et puis on fait pareil, dans le même fichier, mais avec un offset.
            Par exemple tu as une partition cryptée de 2Go, tu en remplis environ 500Mo, et à l'offset 1Go ou 1,5Go, tu recrées une autre partition chiffrée de la même manière.
            Faut faire gaffe : tu as un risque de flinguer la seconde partition en utilisant la première. Et puis c'est théorique, ça peut très bien ne pas fonctionner du tout à cause de la façon dont luks chiffre sa partition.
            Mais si luks chiffre le fichier entier, tu peux malgré tout peut-être créer ta sous-partition à un offset donné de ton device loop, si luks chiffre le device il chiffrera ce qui est caché dedans, et il te faut donc les deux mots de passe en cascade. Monter et déchiffrer le premier pour avoir accès au second.

            Là c'est mieux caché :)

            Ou alors de la stéganographie.

            Yth.

    • [^] # Déni plausible

      Posté par  . Évalué à 3.

      Du coups, je me demandais : existe il une solution permettant pour un volume donné, par exemple, de le splitter en 2 et de déchiffrer la première partie si mot de passe 1, et la seconde si mot de passe 2 ?

      Au moins celle-ci.
      La plupart des autres n’a plus trop l’air maintenue.

      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

  • # chiffrer.info

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

    Je profite de ce journal pour soumettre à votre sagacité ce petit presqu'HS de qualitai : chiffrer.info.

    Peut-être connaissiez-vous déjà.

  • # ctmg

    Posté par  . Évalué à 2.

Suivre le flux des commentaires

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