CONNEXION
  • RetourJeux
    • Tests
    • Soluces
    • Previews
    • Sorties
    • Hit Parade
    • Les + attendus
    • Tous les Jeux
  • RetourActu
    • Culture Geek
    • Astuces
    • Réalité Virtuelle
    • Rétrogaming
    • Toutes les actus
  • RetourHigh-Tech
    • Actus JVTECH
    • Bons plans
    • Tutoriels
    • Tests produits High-Tech
    • Guides d'achat High-Tech
    • JVTECH
  • RetourVidéos
    • A la une
    • Gaming Live
    • Vidéos Tests
    • Vidéos Previews
    • Gameplay
    • Trailers
    • Chroniques
    • Replay Web TV
    • Toutes les vidéos
  • RetourForums
    • Hardware PC
    • PS5
    • Switch
    • Xbox Series
    • Overwatch 2
    • FUT 23
    • League of Legends
    • Genshin Impact
    • Tous les Forums
  • PC
  • PS5
  • Xbox Series
  • PS4
  • One
  • Switch
  • Wii U
  • iOS
  • Android
  • MMO
  • RPG
  • FPS
En ce moment Genshin Impact Valhalla Breath of the wild Animal Crossing GTA 5 Red dead 2
Etoile Abonnement RSS

Sujet résolu : LVM Chiffré et RAM ?

DébutPage précedente
1
Page suivantePage suivante
[Soft]Ware [Soft]Ware
MP
Niveau 39
15 septembre 2020 à 19:52:42

Salut :ok:

Contexte :
J'ai un serveur qui tourne sous FreeNAS et qui permet d'héberger des machines virtuelles (hyperviseur Bhyve).
Je voulais installer un petit Debian Buster 10.5 pour faire des petits tests.
J'ai mis 768Mo de RAM au début (pour éviter l'installation en low memory mod qui est assez chiant, en attendant de mettre du SWAP), et je voulais baisser ensuite à 384Mo (je suis pas sûr que ce soit vraiment une bonne idée mais je voulais au moins essayer). :ok:

Pour le partitionnement, j'ai choisi du LVM Chiffré.
ça s'installe, ça boot, tout va bien.
Un petit reboot, il me demande ma passphrase pour débloquer le volume, ça passe, tout va bien.

Je shutdown, et je baisse la RAM à 384Mo.

Je redémarre, et là, surprise, ma passphrase est incorrecte ! Je suis pourtant sûr à 100% de ce que j'ai mis.

Je rééteins, je repasse la RAM à 768Mo, je redémarre, rentre ma passphrase et là ça fonctionne !

J'ai réessayé une 2eme fois pour être sûr :hap:
Et bien sûr, changer de quantité de RAM est quelque chose que j'ai déjà fait sans problème auparavant, mais sans LVM.

Et donc quoi, j'imagine que la quantité de RAM est utilisée dans le calcul du hashé du mot de passe :( :question:

Comment est gérée la passphrase par LVM ? J'imagine que ce n'est pas le PAM puisque c'est avant le démarrage du système :(

En soi j'ai pas de vrai problème, je peux refaire mon installation en mode low memory, ou même à la limite laisser 768Mo... Mais j'aimerais comprendre :hap:

Donc si y'en a qui savent des choses... Je vous écoute :ok:

:merci:

Pseudo supprimé
Niveau 8
16 septembre 2020 à 13:05:31

Et donc quoi, j'imagine que la quantité de RAM est utilisée dans le calcul du hashé du mot de passe :( :question:

Normalement non, ça n'a rien à voir avec la mémoire vive, mais je me trompe peut-être.

Alors, truc tout bête, qui m'est déjà arrivé, le clavier était passé en QWERTY, donc mot de passe incorrect.

Sinon avec cryptsetup, tu as essayé de changer la passphrase ?

Message édité le 16 septembre 2020 à 13:07:57 par
[Soft]Ware [Soft]Ware
MP
Niveau 39
16 septembre 2020 à 14:23:25

Alors, truc tout bête, qui m'est déjà arrivé, le clavier était passé en QWERTY, donc mot de passe incorrect.

Non, c'est pas ça le problème.
Enfin, oui le clavier est effectivement en QWERTY, mais ça je le savais déjà, et j'ai testé en QWERTY comme en AZERTY, le problème reste le même.
Et de toute façon, avec la quantité de RAM originale, ça fonctionne.

Sinon avec cryptsetup, tu as essayé de changer la passphrase ?

Je peux pas le faire quand j'ai 384Mo de RAM puisque je peux pas accéder au système, le disque étant chiffré... :(
Mais avec les 768Mo de RAM, donc quand ça fonctionne, oui j'ai effectivement essayé de changer la passphrase. J'ai mis un truc tout simple sans chiffre ni caractères spéciaux et qui s'écrit de la même façon en AZERTY ou en QWERTY. Même résultat.

[Soft]Ware [Soft]Ware
MP
Niveau 39
16 septembre 2020 à 14:46:37

Ah par contre j'ai essayé avec 512Mo de RAM et j'ai un résultat différent :
https://image.noelshack.com/fichiers/2020/38/3/1600259196-76743fdcc7d7acfe8b933b843376a1c3.png

Là il me dit plus seulement que le mot de passe est incorrect, mais aussi que j'ai pas assez de RAM !
C'est quand même ballot que j'ai pas ce message avec 384Mo de RAM :hap: J'imagine qu'il n'avait pas assez de RAM pour me prévenir qu'il n'avait pas assez de RAM... :rire:

La config minimale annoncée pour Debian demande pourtant 128Mo de RAM (sans interface graphique), mais c'est sans doute sans LVM et/ou sans chiffrement :(

Par ailleurs je me rends compte que le SWAP ne peut pas être utilisé à ce moment là, puisque la partition de SWAP a été créée par l'assistant à l'installation en LVM, donc c'est dans la partition chiffrée, donc tant que c'est pas déchiffré, le SWAP n'est logiquement pas accessible :hap:

Du coup j'imagine que je devrais faire une partition LVM d'un côté qui serait elle chiffrée, et à côté une partition SWAP plus classique :(

[Soft]Ware [Soft]Ware
MP
Niveau 39
16 septembre 2020 à 14:55:21

D'ailleurs j'avais pas fait gaffe mais j'étais allé voir la config minimale de Debian Jessie :hap:

Pour Debian Buster, c'est 256Mo le minimum
https://www.debian.org/releases/buster/amd64/ch03s04.fr.html

Donc je suis pas si large que ça :(

[Soft]Ware [Soft]Ware
MP
Niveau 39
16 septembre 2020 à 15:36:31

Du coup je suis bloqué :
https://www.noelshack.com/2020-38-3-1600263263-2abe6d8a6ebd905c67c550610bcc5718.png

Je peux pas créer de SWAP à l'extérieur du volume chiffré, et effectivement c'est logique, ça a beau jouer le rôle de RAM, ça reste de l'espace disque, donc non effacé à l'extinction de la machine :(

Donc ou bien je fais une machine avec un peu plus de RAM, ou bien je ne chiffre pas mon disque :(

godrik godrik
MP
Niveau 21
16 septembre 2020 à 17:06:40

tu pourrais envisager avoir une swap pour booter et changer de swap une fois LVM initialise. Ca te permettrait de remettre a 0 la swap non chiffre.
La machine sous freenas est a toi? Si oui, ca pourrait etre plus simple de laisser freenas s'occuper du chiffrement et laisser la VM debian avec un LVM non chiffree.

[Soft]Ware [Soft]Ware
MP
Niveau 39
17 septembre 2020 à 22:37:51

tu pourrais envisager avoir une swap pour booter et changer de swap une fois LVM initialise. Ca te permettrait de remettre a 0 la swap non chiffre.

Ah ouais ? Tu connais la procédure à suivre ? Parce que là je vois pas bien :(

J'ai tenté une nouvelle installation (avec 384MB de RAM) :
https://www.noelshack.com/2020-38-4-1600371726-57690977927892263612ca66c399d28a.png

Pas moyen de continuer, il refuse d'utiliser ma partition SWAP non chiffrée.
Si je supprime la partition SWAP on connaît la suite, il ne pourra pas démarrer (pas assez de RAM pour déchiffrer).

Du coup j'ai relancé l'installation mais avec 768MB de RAM, j'ai fait tout pareil que le screen précédent, mais je n'ai pas activée le swap non chiffré (la partition existe mais non utilisée).

Donc ensuite l'idée c'est de créer une partition swap dans la partition vide (jusque là ça devrait aller), et ensuite de faire un changement automatique du swap au démarrage... Et là je suis pas trop sûr de comment faire ?!

La création de la partition swap avec mkswap ok c'est facile.

Ensuite je dois ajouter ce nouveau swap dans le fstab. Je prends la ligne correspondante au swap déjà existant et je change juste le chemin de la partition.

Maintenant je redémarre, sans toucher à la RAM. Ça démarre normalement, le disque est correctement déchiffré. Je vois bien que mes 2 partitions SWAP sont activées.

Maintenant j'éteins, je diminue la RAM, et redémarre. Eh bien j'ai à nouveau le même problème, il refuse de déchiffrer la partition. J'imagine que le swap non chiffré n'est pas encore monté. Mais je ne sais pas comment lui spécifier de le monter en premier ?
Voici mon fstab :

/dev/sda3 none            swap    sw,pri=9              0       0
/dev/mapper/DebianCA--vg-LVM_root /               ext4    errors=remount-ro 0       1
UUID=6e16892a-6307-4c58-af4c-bc44fa0abb16 /boot           ext2    defaults        0       2
UUID=977C-9529  /boot/efi       vfat    umask=0077      0       1
/dev/mapper/DebianCA--vg-LVM_swap none            swap    sw,pri=-2              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

La seule chose que j'ai modifié c'est la première ligne ainsi que l'option pri=x pour les deux swap. Mais je ne suis pas sûr de comprendre l'intérêt de cette option ? Elle n'apparaît pas dans le manuel fstab.
Mais je retrouve ces priorités avec la commande swapon -s. J'imagine que c'est la priorité d'utilisation des partitions lorsque des données sont mises en swap, et rien à voir avec le fstab ?
Alors comment je lui spécifie de monter mon swap non chiffré en premier ? Est-ce que c'est ne serais-ce que possible ?

Et puis ensuite, comment je désactive le SWAP non chiffré une fois le système démarré ?
swapoff devrait être la solution, mais je ne vois rien dans le man qui me garantisse que la partition sera effacée ?
Et à quel moment je devrais exécuter cette commande ? Il faudrait le faire le plus tôt possible, mais après le déchiffrement de la partition bien sûr :( A quel endroit du système je devrais spécifier ça ?

La machine sous freenas est a toi? Si oui, ca pourrait etre plus simple de laisser freenas s'occuper du chiffrement et laisser la VM debian avec un LVM non chiffree.

Oui c'est à moi.
Mais j'ai pas de réelle utilité à chiffrer ça, y'aura rien d'important dessus.
Le but c'est surtout de maîtriser au mieux Debian, faut juste voir ça comme un exercice :oui:

godrik godrik
MP
Niveau 21
18 septembre 2020 à 01:40:30

J'ai envie de dire que je ferais comme partout. Je rajouterais deux targets dans le boot sequence. Un qui monte la swap non chiffre et qui vient avant le montage lvm dans la sequence de boot, et un qui swapoff et qui vient apres le montage de la swap plus grosse.

Mais fondamentalement, je pense qu'il te faut plus de RAM pour faire du LVM chiffre.

J'imagine que tu as vu l'option --pbkdf-memory de crypt-setup?

[Soft]Ware [Soft]Ware
MP
Niveau 39
20 septembre 2020 à 18:34:07

Ouais, le fstab c'était pas une super idée, puisqu'il se trouve dans la partition chiffrée... :hap:
Donc effectivement ça change rien et c'est totalement logique.

Alors le boot sequence pour le coup je maîtrise pas du tout, du tout, du tout... :hap:
Bon logiquement je vais devoir travailler dans le /boot qui est la seule partition non chiffrée, et qui contient justement le boot sequence si je ne m'abuse. Et plus précisément c'est le grub que je devrais personnaliser :(
Pour le moment je sais pas encore comment je vais faire ça, j'ai pas trop trouvée de documentation satisfaisante :( (mais j'ai encore que peu cherché).

Ouais ouais, plus de RAM ça j'ai bien compris :hap: J'aimerais bien réussir ce petit défi quand même :rire:

Et non j'ai pas du tout vu cette option de cryptsetup !
Mais alors qu'est-ce que ça change fondamentalement ? L'utilisation CPU sera plus importante pour déchiffrer tout ça, et donc un temps de déchiffrement plus élevé, mais c'est tout ? Pas de dégradation du chiffrement ?
Mais s'il n'y a pas de dégradation du chiffrement, alors pourquoi la fonction ne s'adapte pas directement à la quantité de mémoire disponible ?

godrik godrik
MP
Niveau 21
20 septembre 2020 à 22:14:09

En vrai, je ne sais pas. Ke n'ai jamais regarde comment crypt_setup fonctionne. Mais j'ai vu dans plusieurs article que par default l'encryption utilise par default brule en gros 500MB de ram. Ca a l'air consistent avec le probleme que tu as.

Et en effet, je pense que reduire l'espace de pdkdf utilise va diminuer la securite de l'encyption obtenu. Il faudrait regarder ce que fait le systeme plus en detail pour pouvoir savoir quoi faire. J'ai l'impression en lisant ca ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924560 ) que crypt-setup se configure en fonction de l'espace memoire disponible a l'installation.

Grey-Kangaroo Grey-Kangaroo
MP
Niveau 12
21 septembre 2020 à 19:36:46

Salut.

Pourquoi tu ne chiffre pas ton serveur ou alors l'emplacement où sont stockés tes VMs ?

Cela me semble beaucoup plus simple comme approche... et au final cela empêchera d'accéder à tes données.

[Soft]Ware [Soft]Ware
MP
Niveau 39
27 septembre 2020 à 15:13:45

Bon j'ai plus de temps à y consacrer, je vais laisser avec 768Mo de RAM :noel:

Le 21 septembre 2020 à 19:36:46 Grey-Kangaroo a écrit :
Salut.

Pourquoi tu ne chiffre pas ton serveur ou alors l'emplacement où sont stockés tes VMs ?

Cela me semble beaucoup plus simple comme approche... et au final cela empêchera d'accéder à tes données.

C'est déjà chiffré :noel:
Mais le but c'est surtout la manipulation du truc, pas d'avoir réellement du chiffrement, parce que y'a rien d'important dessus finalement.

[Soft]Ware [Soft]Ware
MP
Niveau 39
27 septembre 2020 à 18:56:41

Bon bah problème résolu :fete:

sudo cryptsetup luksDump /dev/sda4

ça me donne des informations sur les algos utilisés, notamment :

Key:        512 bits
Priority:   normal
Cipher:     aes-xts-plain64
Cipher key: 512 bits
PBKDF:      argon2i
Time cost:  5
Memory:     375822
Threads:    1

Du coup j'ai utilisé cryptsetup-reencrypt
https://www.systutorials.com/docs/linux/man/8-cryptsetup-reencrypt/

J'ai monté le disque sur une autre machine, puisque forcément le volume ne doit pas être ouvert pour pouvoir travailler dessus (il est totalement verrouillé et inaccessible pendant l'opération).

Et puis j'ai refait le chiffrement :
sudo cryptsetup-reencrypt --pbkdf argon2id --pbkdf-memory 13107 /dev/sdb4
Donc il a écrit sur l'intégralité du volume, heureusement c'est que 7Go et sur SSD donc ça a pris à peine 3 minutes.

Si je refais la commande de toute à l'heure :

sudo cryptsetup luksDump /dev/sda4
Key:        512 bits
Priority:   normal
Cipher:     aes-xts-plain64
Cipher key: 512 bits
PBKDF:      argon2id
Time cost:  199
Memory:     13107
Threads:    1

On voit que la mémoire a été effectivement diminuée, par contre le coût en temps a été multiplié par presque 40... :rire:
Mais en pratique ça se voit pas vraiment, ça prend largement moins de 5 secondes :ok:

Et donc maintenant je peux reboot avec 384Mo de RAM et ça fonctionne très bien :content:

Message édité le 27 septembre 2020 à 19:00:24 par [Soft]Ware
[Soft]Ware [Soft]Ware
MP
Niveau 39
28 septembre 2020 à 15:31:10

Le 28 septembre 2020 à 08:29:45 bladelores a écrit :
Et y'avait pas besoin d'utiliser reencrypt tu pouvais juste utiliser un nouveau keyslot et supprimer l'ancien

Ouais, j'ai douté de ça, après avoir utilisé reencrypt... :hap:

godrik godrik
MP
Niveau 21
28 septembre 2020 à 17:03:13

Est ce que quelqu'un peut clarifier si le changement du montant de mémoire utilisée impacte la qualité du chiffrement?

[Soft]Ware [Soft]Ware
MP
Niveau 39
11 octobre 2020 à 21:06:25

Autre question à propos de cryptsetup :

La partition est déchiffrée en totalité ou bien selon les besoins d'accès ?

J'ai mis ça en place sur mon PC principal, qui a certes une bonne config (CPU 6C/12T, 32Go RAM, 500Go NVMe3), mais le déchiffrement me paraît assez fou, c'est genre quasi instantané ! En tout cas ça prend moins d'une seconde...

Comment ça se fait ?
Est-ce que c'est vraiment toute la partition qui est déchiffrée, ou seulement des morceaux "utiles" ?

Est-ce que par exemple on pourrait imaginer que seul le superblock soit déchiffré, et ensuite qu'on déchiffre les fichiers à chaque fois qu'un accès est demandé ? Mais ça doit ralentir le système :(

Et puis je m'interroge sur la qualité de mon Keyslot :

Keyslots:
  0: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2i
	Time cost:  4
	Memory:     924187
	Threads:    4

Bon déjà c'est du argon2i et pas du argon2id... C'est dommage :(
Il y a "seulement" 1Go de RAM utilisé, alors que 32Go sont disponibles.
Et seulement 4 threads utilisés, alors que 12 sont disponibles :(

:merci:

[Soft]Ware [Soft]Ware
MP
Niveau 39
15 octobre 2020 à 19:49:35

Le 11 octobre 2020 à 21:25:21 OnVaCrever a écrit :

Est-ce que c'est vraiment toute la partition qui est déchiffrée, ou seulement des morceaux "utiles" ?

Chaque block est décrypté à la demande, et les instructions AES du CPU permettent de rendre ça très rapide, la seule partie qui est censée prendre du temps c'est la dérivation de clé, une fois avec la clé entre les mains c'est trivial de déchiffrer (tu peux utiliser cryptsetup benchmark pour voir les vitesses des différents algos)

C'est vrai, je me souviens maintenant qu'il y a des instructions CPU pour AES :oui:

Par contre comment tu sais que les blocs sont déchiffrés à la demande ? J'ai essayé de trouver une source +/- officielle et j'ai pas trouvé :(

Pour les benchmark sur ma machine Ryzen 3600X avec DDR4 3600MHz :
https://image.noelshack.com/fichiers/2020/42/4/1602783668-crypt-bench.png

Y'a quand même une grosse différence de vitesse de déchiffrement entre CBC et XTS à taille de clé équivalente (256bits :d) ce qui reste supérieur à la taille de clé recommandée par l'ANSSI :d) https://www.ssi.gouv.fr/uploads/2015/01/RGS_v-2-0_B1.pdf page 10 )

Mais est-ce qu'il y a une différence de qualité entre CBC et XTS ? Peut-être des vulnérabilités en CBC ?

Bon déjà c'est du argon2i et pas du argon2id... C'est dommage :(

Libre à toi de refaire un slot (créer un nouveau et supprimer l'ancien), tu peux le faire avec le volume monté je crois, je me rappelle plus trop

Le mien à titre de comparaison, j'ai mis 4G de ram sur 4 threads et 25 time cost, il met environ 6 secondes à dériver la clé

Oui, on peut :
sudo cryptsetup luksAddKey /dev/nvme0n1p3 --pbkdf argon2id --pbkdf-memory 4194304 --pbkdf-parallel 4

A noter que le nombre max de threads est de 4 :
--pbkdf-parallel <number> Set the parallel cost for PBKDF (number of threads, up to 4). Note that it is maximal value, it is decreased automatically if CPU online count is lower. This option is not available for PBKDF2.

Et pour ce qui est de la quantité de mémoire, c'est une quantité maximale :
--pbkdf-memory <number> Set the memory cost for PBKDF (for Argon2i/id the number represents kilobytes). Note that it is maximal value, PBKDF benchmark or available physical memory can decrease it. This option is not available for PBKDF2.

Dans mon cas il n'a gardé que 2537864 ko, pourquoi une telle différence ? (j'ai demandé 4go sur 32go disponibles) Et pourquoi toi tu as bien 4go du coup ?

Pour ce qui est du hash, je comprends pas bien à quel moment ça sert ?
En tout cas pour changer d'algo (par défaut sha256), je dois rechiffrer la partition (cryptsetup reencrypt).

:merci:

DébutPage précedente
1
Page suivantePage suivante
Répondre
Prévisu
?
Victime de harcèlement en ligne : comment réagir ?
La vidéo du moment