Journal un vrai coffre fort numérique

Posté par Osourcier le 31 août 2016 à 12:42. Licence CC By‑SA.

Étiquettes :

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=512on 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.imgFormater 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/loop0il 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.imgUtilisation :

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 tmpet 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 BFG le 31 août 2016 à 12:46. Évalué à 2.

Vous pouvez contribuer à LinuxFR sur son wiki.
- [^] # Re: Wiki
  
  Posté par Adminrezo (site web personnel) le 31 août 2016 à 13:13. É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 Osourcier le 31 août 2016 à 13:20. É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 Osourcier le 31 août 2016 à 13:39. Évalué à 2.
    
    Bon mis dans le wiki, mais ces balises code décidément je n'y arrive pas :/
    - [^] # Re: Wiki
      
      Posté par Dreammm le 31 août 2016 à 14:22. Évalué à 1.
      
      balises de code mises à jour, tu peux voir du coup que ce n'est pas compliqué.
# Image luks détectable

Posté par Christophe HENRY (site web personnel) le 31 août 2016 à 14:06. É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 julmx le 31 août 2016 à 17:27. É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 gUI (Mastodon) le 31 août 2016 à 17:59. É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 Nicolas Boulay (site web personnel) le 01 septembre 2016 à 11:30. É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 mut le 31 août 2016 à 14:07. Évalué à 4.
```
sudo cryptsetup luksOpen /dev/loop0 disque-secret.img
```
- [^] # Re: Il manque une ligne
  
  Posté par phantez (site web personnel) le 31 août 2016 à 15:14. Évalué à 1.
  
  Effectivement il manque luksOpen à l'initialisation avant d'utiliser mkfs.ext4.
  - [^] # Re: Il manque une ligne
    
    Posté par Osourcier le 31 août 2016 à 15:24. Évalué à 2.
    
    ooops tout juste !
- [^] # Re: Il manque une ligne
  
  Posté par steph1978 le 06 septembre 2016 à 12:49. Évalué à 2.
  d'ailleurs, pourquoi déclarer un device mapper avec le même nom que le fichier.
  une trace inutile.
```
sudo cryptsetup luksOpen /dev/loop0 toto
```
# truncate à la place de dd

Posté par millman le 31 août 2016 à 14:23. É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 gUI (Mastodon) le 31 août 2016 à 18:00. É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 Minux13 le 02 septembre 2016 à 12:47. Évalué à 4.
    
    "fallocate -l 2GB disque-secret.img" est plus parlant.
    - [^] # Re: truncate à la place de dd
      
      Posté par steph1978 le 06 septembre 2016 à 13:10. É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 steph1978 le 06 septembre 2016 à 12:50. É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 Liorel le 31 août 2016 à 14:30. É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 Osourcier le 31 août 2016 à 15:07. É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 Liorel le 31 août 2016 à 16:08. É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 Osourcier le 31 août 2016 à 16:44. É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 gUI (Mastodon) le 31 août 2016 à 18:01. É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 steph1978 le 06 septembre 2016 à 12:55. É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 gouttegd (site web personnel) le 31 août 2016 à 18:45. É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 Osourcier le 31 août 2016 à 19:54. É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 steph1978 le 06 septembre 2016 à 13:25. É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 gouttegd (site web personnel) le 06 septembre 2016 à 14:29. É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 steph1978 le 08 septembre 2016 à 16:57. É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 Marotte ⛧ le 31 août 2016 à 20:05. É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.
- [^] # Re: Moi aussi j’y vais de mon script.
  
  Posté par Osourcier le 31 août 2016 à 20:21. Évalué à 2.
  
  cool je peut supprimer le script bash a 2 francs que j'avais pondu^{^} c'est cool le web quand même !
# Chipotage

Posté par Alex G. le 31 août 2016 à 22:20. É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…
- [^] # Re: Chipotage
  
  Posté par Osourcier le 31 août 2016 à 22:50. Évalué à 1.
  
  c'est pas contradictoire ceci dit
# Petite question, en parlant de ça...

Posté par neuro le 31 août 2016 à 23:10. É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 Marotte ⛧ le 01 septembre 2016 à 06:02. É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 Yth (Mastodon) le 01 septembre 2016 à 08:58. É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 gouttegd (site web personnel) le 01 septembre 2016 à 09:28. É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 chimrod (site web personnel) le 01 septembre 2016 à 09:44. É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 Osourcier le 01 septembre 2016 à 10:37. É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 Yth (Mastodon) le 01 septembre 2016 à 10:39. É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 Arthur Accroc le 01 septembre 2016 à 07:23. É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 Thomas (site web personnel) le 01 septembre 2016 à 11:33. É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à.
- [^] # Re: chiffrer.info
  
  Posté par Christophe HENRY (site web personnel) le 01 septembre 2016 à 14:14. Évalué à 1.
  
  Pour un béotien, c'est plutôt cryptique.
# ctmg

Posté par RD le 08 septembre 2016 à 02:42. Évalué à 2.

https://git.zx2c4.com/ctmg/about/

Suivre le flux des commentaires

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