16ar Posté(e) le 17 décembre 2007 Partager Posté(e) le 17 décembre 2007 Je souhaite formatter une clé usb totalement et la rendre completement chiffrée (donc le peripherique entierement, pas juste la partition. Ca permet d'avoir la table de partition chiffré idem) pour le moment j'ai fais un : dd if=/dev/zero of=/dev/sda puis : cryptsetup -y create cleusb /dev/sda Enfin j'y ai accedé avec gparted et j'ai crée une nouvelle table de partition. Pour compliquer la tache, j'ai mis une table de partition BSD, ca sera moins courant que du MSDOS. J'imagine que tout ce que reconnait gparted comme table de partition reste assez courant ? Vous me conseillez autre chose que BSD pour etre un peu plus exotique ? (tout en etant reconnu facilement/nativement sous linux) Seulement voila, je me suis rendu compte que j'avais oublié de passer par LUKS pour le cryptsetup... Du coup je refais tout et j'ai lancé un : dd if=/dev/random of=/dev/sda Seulement, c'est lent... EXTREMEMENT lent. En 10 min, ca a copié 4ko ... J'ai changé la frequence des 2 cores a fond (2 Ghz), néanmoins ca change rien, c'est lent. Sur un tutorial, ca indiquait environ 5 min pour 1 Go. J'ai 2 Go et c loin d'etre fini ... Est ce parce que le support est une clé usb en flash ? Merci de vos avis/conseils. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Compte_supprime_74291 Posté(e) le 17 décembre 2007 Partager Posté(e) le 17 décembre 2007 Normal; pour /dev/random... c'est un générateur aléatoire qui se base sur l'entropie générée par le système à un instant t... par exemple, bouger la souris augmente le flux dans /dev/random (où du moins, remplit le pool d'entropie qui permet d'augmenter le flux de /dev/random)... mais attendre qu'il génère du bruit avec tous les process coupés, ça réduit le flux dans /dev/random... ... si tu veux un générateur d'entropie plus rapide, tout en restant "correct", il faut aller voir dans /dev/urandom, qui est capable de ne pas se limiter au pool d'entropie présent à l'instant t... les données qui en sortent sont moins aléatoires que ce qui sort d'un /dev/random, mais pour vouloir faire un dd de ce node dans une partition de, ne serait-ce que, plusieurs Mio, faut le vouloir ... autant investir dans un générateur matériel de bruit ou monter un cluster de machines devant en générer, si le risque est si important qu'on ne doive pas se satisfaire de /dev/urandom... Sinon, ne t'emballe pas trop non plus à répéter ce genre d'opérations sur une clé USB... j'ai déjà cramé quelques Corsair comme ça... Edit : autrement, avec LUKS (et avec dm-crypt tout court, a priori), note bien que ta partition ne sera pas cachée... elle présentera une entête LUKS (ou dm-crypt) reconnaissable par tous les bons HAL... elle sera chiffrée, mais pas camouflée... ... stéganographier (et cie) la partition, ça passe par d'autres outils, comme truecrypt, qui a ceci dit le mauvais goût d'arborer une licence des plus obscures... à l'origine, c'est un adware qui demande que quiconque le distribue en fasse de la pub sur le support et un peu partout... il semble que ça ait été modifié depuis; mais je l'ai lu il y a peu, et ça reste quand même obscur et pas très net... Lien vers le commentaire Partager sur d’autres sites More sharing options...
16ar Posté(e) le 17 décembre 2007 Auteur Partager Posté(e) le 17 décembre 2007 Normal; pour /dev/random... c'est un générateur aléatoire qui se base sur l'entropie générée par le système à un instant t... par exemple, bouger la souris augmente le flux dans /dev/random (où du moins, remplit le pool d'entropie qui permet d'augmenter le flux de /dev/random)... mais attendre qu'il génère du bruit avec tous les process coupés, ça réduit le flux dans /dev/random...... si tu veux un générateur d'entropie plus rapide, tout en restant "correct", il faut aller voir dans /dev/urandom, qui est capable de ne pas se limiter au pool d'entropie présent à l'instant t... les données qui en sortent sont moins aléatoires que ce qui sort d'un /dev/random, mais pour vouloir faire un dd de ce node dans une partition de, ne serait-ce que, plusieurs Mio, faut le vouloir ... autant investir dans un générateur matériel de bruit ou monter un cluster de machines devant en générer, si le risque est si important qu'on ne doive pas se satisfaire de /dev/urandom... Sinon, ne t'emballe pas trop non plus à répéter ce genre d'opérations sur une clé USB... j'ai déjà cramé quelques Corsair comme ça... De quoi ? Les dd ? ou les chiffrages sur clé usb ? Mais sinon, un dd, ca compte comme 1 ecriture, non ? Ca en fait pas 25 sur le meme cluster, si ? Edit : autrement, avec LUKS (et avec dm-crypt tout court, a priori), note bien que ta partition ne sera pas cachée... elle présentera une entête LUKS (ou dm-crypt) reconnaissable par tous les bons HAL... elle sera chiffrée, mais pas camouflée... ... stéganographier (et cie) la partition, ça passe par d'autres outils, comme truecrypt, qui a ceci dit le mauvais goût d'arborer une licence des plus obscures... à l'origine, c'est un adware qui demande que quiconque le distribue en fasse de la pub sur le support et un peu partout... il semble que ça ait été modifié depuis; mais je l'ai lu il y a peu, et ça reste quand même obscur et pas très net... Ah zut, je savais pour LUKS, du coup j'ai fait ca pour rien, je l'ai bien dans le LUKS pour le coup :( Lien vers le commentaire Partager sur d’autres sites More sharing options...
lorinc Posté(e) le 17 décembre 2007 Partager Posté(e) le 17 décembre 2007 le truc que tu peux faire pour augmenter le debit de /dev/random, c'est compiler un truc en parallèle (avec des options genre -pipe, etc...) Lien vers le commentaire Partager sur d’autres sites More sharing options...
Compte_supprime_74291 Posté(e) le 17 décembre 2007 Partager Posté(e) le 17 décembre 2007 Mais sinon, un dd, ca compte comme 1 ecriture, non ? Ca en fait pas 25 sur le meme cluster, si ? L'origine du problème, je pense qu'elle vient plus de l'utilisation d'un système chiffré que de dd (en effet, si on ne s'en sert qu'une seule fois, et qu'on ne modifie pas les partitions après, ça n'est censé écrire qu'une fois), mais au bout de quelques mois de testage intensif, j'en ai cramé deux (et j'ai moins confiance en la troisième bon, ce sont des 128Mio, je ne vais pas pleurer)... ceci dit, je n'ai pas lésiné sur le dd de urandom non plus... Ah zut, je savais pour LUKS, du coup j'ai fait ca pour rien, je l'ai bien dans le LUKS pour le coup :( Ceci dit, LUKS marche quand même très bien... je préfère lui faire confiance (en plus, au moins il est dispo partout) que de me baser sur un truc avec des clauses douteuses dans la licence (genre truecrypt, ce n'est pas chez Debian... et je crains que l'adoucissement de sa licence quant à la publicité, obligatoire de marquer "based on truecrypt" si c'est possible, ne suffise pas... écrire ça sur un paquet, OK, c'est pas forcément ultra-simple... bon, on pourrait imaginer écrire ça dans un fichier... mais si tu te graves un CD Debian ou que tu en distribues, si c'est déjà écrit dans un fichier de licence, faut se le retaper sur le label du CD? Ca ne m'a pas l'air très clair, et c'est dommageable à la diffusion de ce projet, pourtant conceptuellement intéressant, ce qui le rend moins pérenne à mes yeux...)... ... et je considère de toute façon l'idée de ne pas perdre la clé et de ne pas y stocker de choses qui ne peuvent être changées comme infiniment plus sûre que de la stégano (celle sur laquelle je stocke tous mes scripts Debian, et où il y a par exemple le schéma d'adressage de mon réseau, je peux la perdre: avant de déchiffrer de l'AES-256, j'aurais eu le temps de le changer, le plan d'adressage... et itout pour les clés SSH et GPG chiffrées dessus...)... ... après, si tu veux stocker des choses pour qu'il n'y ait aucune chance qu'on les découvre, le mieux est de les mettre sur un support que tu pourras cacher et détruire au besoin, comme un disque optique si tu as un broyeur ou un chalumeau ... ce qui n'empêche ceci dit pas de chiffrer... Mais si tu as besoin de te déplacer avec des choses qui ne doivent pas être découvertes et qui ne peuvent pas être révoquées, ou périmées, bah, oui... faudrait de la stégano... mais étendre ça à l'échelle d'une partition (moins discret que dissimulé dans de la merde évidente, a priori), avec du libre (et pas de l'adware déguisé), ça demande un outil dont je ne connais pas encore l'existence... le truc que tu peux faire pour augmenter le debit de /dev/random, c'est compiler un truc en parallèle (avec des options genre -pipe, etc...) Ouais, enfin, /dev/random, c'est surtout fait pour générer de petits fichiers aléatoires... comme des clés de chiffrement... mais pour une partition, /dev/urandom est quand même beaucoup plus accessible (urandom sollicite pas mal de ressources CPU, ce qui génère de l'entropie, faisant que le pool de celle-ci est quand même infiniment plus aléatoire que /dev/zero, lorsqu'on s'amuse à traire /dev/urandom... moins que lorsqu'on s'amuse à traire /dev/random, certes, certes... mais faut comparer ce qui est comparable en flux de bruit aléatoire)... Edit: sinon, en y repensant, la santé de la clé USB vient sans nul doute du fait que je les monte en "sync"... ce qui me permet de les débrancher comme un goret si j'en ai envie... ça marche bien, ça ne corrompt rien (si je ne m'en servais pas à ce moment-là), mais couplé au chiffrement et à dd, ça peut vraissemblablement aussi expliquer pourquoi j'en ai cramé quelques une Lien vers le commentaire Partager sur d’autres sites More sharing options...
16ar Posté(e) le 17 décembre 2007 Auteur Partager Posté(e) le 17 décembre 2007 Pour de la stegano, y'a bien StegFS : http://www.mcdonald.org.uk/StegFS/ Mais bon, je ne sais pas si c'est utilisable facilement, fiable ou autre. Y'avait bien des rapport/bench fait a ce niveau. Mais mes données sont du meme genres que les tiennes : clé ssh/gpg, quelques acces password. Sachant que je ne suis pas de la DST, c'est pas comme si on allait mettre un cluster sur la clé usb pour la déchiffrer... Mais c'est tellement geek d'avoir une clé sécurisée ! Lien vers le commentaire Partager sur d’autres sites More sharing options...
Compte_supprime_74291 Posté(e) le 17 décembre 2007 Partager Posté(e) le 17 décembre 2007 Ca a l'air un peu mort, stegfs, non? Bon, sinon, pour le chiffrement, personnellement, je ne l'utilise pour rien qui ne puisse être révoqué... donc, je ne l'utilise que pour éviter que le premier grouillot puisse accéder à des données importantes (en gros, les noms de mes utilisateurs et des choses du genre) en un coup de cuiller à pot... et sur toutes mes machines pour chiffrer le swap et /tmp avec une clé aléatoire générée à chaque boot (surtout pour ne pas avoir à m'inquiéter des applications qui laissent de la merde dans /tmp, même s'il est de toute façon effacé, j'aime autant le défourailler)... ... pas pour me protéger des chinois du fbi (ça implique de toutes autres précautions que je n'ai pas les moyens de me procurer )... on ne vit pas tous une vie d'agents secrets et de dangereux terro-pédophiles du machinkistan, non plus... Et puis... LUKS est sécurisé... si tu l'utilises proprement, ça te permet de chiffrer en AES 256... tous les tokens crypto ne sont même pas forcément capables de générer ce genre de clés (et puis de toute façon, la gestion des tokens cryptos par les distros binaires est quand même très moyenne, pour être poli... ce qui est bien dommage, d'ailleurs)... si tu utilises une passphrase assez complexe (voir de la taille de la clé, et chiffrée sur un autre périphérique... c'est faisable, même si c'est chiant à gérer sur le long terme... et puis, faut bien à un stade ou à un autre une passphrase ou une clé en clair, ce qui est le gros défaut vis à vis d'un token matériel, d'autant plus qu'une clé ne sort pas d'un token, alors qu'elle est stockée en clair en mémoire, lors de son utilisation, si tout se fait en logiciel), ça te laisse pas mal de temps pour prendre les mesures que tu dois prendre en cas de perte de la clé ou de soupçon qu'on en a fait une image... Par contre, niveau geek qui s'intéresse à la possibilité de préserver un tantinet de vie privée, il y a moyen de s'intéresser à d'autres choses... le HDD système de mon serveur P2P vient de lâcher... et plutôt que de repartir sur un backup, je serais plutôt tenté de diversifier les capacités de la machine en mettant en place un noeud freenet, et un serveur gnunet, en plus de remettre sur pied mon noeud tor, et de continuer à utiliser mldonkey ( )... occasion qui serait manquée si je ne m'essayais pas à quelque chose d'un peu plus cornu pour séparer tout ça qu'un antique chroot (mais vserver, je ne sais pas... je serais plus partant sur un XEN ... par contre, va falloir s'essayer à OCFS2 dans ce cas, que je ne connais pas du tout)... bref, il y a toujours à faire Lien vers le commentaire Partager sur d’autres sites More sharing options...
16ar Posté(e) le 18 décembre 2007 Auteur Partager Posté(e) le 18 décembre 2007 Euh, Aefron, tu as dit que n'importe quel outil HAL pouvait voir la table de partition chiffrée. Mais pour ce que j'en viens d'en tester, ma table de partition est invisible pour fdisk, cfdisk, et parted. Je pense que ca fait deja pas mal. Pourtant j'ai utilisé luks :) Du coup, meme si c'est pas de la stegano, ca peut deja faire croire qu'il n'y a rien sur la clé... Mais bon, ubuntu 7.10 semble reconnaitre les partition chiffrée et du coup mon systeme n'est pas "reconnu" avec prompt password via le gui. Je dois avouer que ca doit etre pas mal ,donc je vais faire une partoche que je chiffrerai et je verrais si c'est mieux reconnu par ubuntu du coup. Si non, je retourne a ma cle entierement chiffrée :) Lien vers le commentaire Partager sur d’autres sites More sharing options...
Compte_supprime_74291 Posté(e) le 18 décembre 2007 Partager Posté(e) le 18 décembre 2007 En même temps, cfdisk et cie, dans le genre avares d'informations... même les trucs comme gparted ne cassent pas trois pattes à un canard... ça sait bien gérer les partitions couramment utilisées, mais faut pas trop en demander dès qu'on sort de ext/fat/reiser... Essaye avec les infos venant direct de HAL... genre "hal-device-manager", je crois, devrait te donner bien plus de renseignements... LUKS y était clairement spécifié, la dernière fois que j'ai regardé, et il me semble que c'est aussi la même chose pour dm-crypt en général... Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.